Opened 19 months ago

Closed 19 months ago

Last modified 19 months 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


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.

Attachments (0)

Change History (3)

comment:1 Changed 19 months 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 19 months ago by aaugustin (previous) (diff)

comment:2 Changed 19 months 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 19 months 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!

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.