Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#19022 closed Uncategorized (invalid)

Connection reset by peer with development server.

Reported by: tdhutt@… Owned by: nobody
Component: Uncategorized Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When running the development server both with and without --nothreading, sometimes we get connection reset by peer errors. We are using Chrome and not sending any POST or GET parameters, and it works most of the time. It seems to be when there are lots of connections in a row or concurrent connections that it has issues. Clearly it should be able to handle that without resetting the connection, even if it only processes the requests serially. There's no reason it shouldn't work when running multithreaded either.

There are various other bugs in the database related to this, but they all appear to be closed or marked as duplicates of unrelated bugs and this is still an issue. See especially #18126.

Change History (3)

comment:1 Changed 2 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

"connection reset by peer" usually means that the browser closed the connection prematurely. For instance it happens when you move to a new page while the assets of the previous page are still loading. This is harmless, it's just how browsers work. There's no point in loading an asset that isn't necessary any longer.

#18126 talks of using runserver in production under high load, this is definitely something you mustn't do (see the docs).

Last edited 2 years ago by aaugustin (previous) (diff)

comment:2 Changed 2 years ago by tdhutt@…

Sorry I probably wasn't clear enough in my original report - the "connection reset by peer" error shows up in the browser, not on the django console. It also shows up when using the Apache java HTTP client, so I'm 99.9% sure this is a django problem and not the fault of the client.

Also I can't see how high loads should cause bugs like this.

comment:3 Changed 2 years ago by aaugustin

Ah, indeed, I hadn't understood the errors were in the browser.

This happens whenever the development server autoreloads while the browser is downloading a page.


I can't see how high loads should cause bugs like this.

High loads make downloads longer, increasing the likelihood of being interrupted by an autoreload.

If this happens outside of autoreloads, well, I don't have an obvious answer, but there's a reason why we use application servers (gunicorn, uwsgi, etc.). I'm not really a systems guy, but I'm sure someone else could explain that!

Note: See TracTickets for help on using tickets.
Back to Top