error: [Errno 32] Broken pipe

[brycenesbitt]

For reasons I don't fully understand, about one in 50 of django-autocomplete-light's ajax queries return with Broken Pipe on my server:

Traceback (most recent call last):
  File "/usr/lib/python2.7/socket.py", line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
Exception happened during processing of request from ('127.0.0.1', 43082)
[03/Jun/2014 20:20:26] "GET /ac/?q=this+is+a+test+sdklf HTTP/1.1" 200 12

This would go unnoticed in most cases, except for this global error handler:

$( document ).ajaxError(function(e,jqXHR) {
  alert('An error has occurred.  Please reload the page.  If the problem persists, please report to the administrators. Code ' + jqXHR.status + '.');
});

Is there a way to override the default error handler for yourlabsAutocomplete ?
See http://stackoverflow.com/a/7436344/311364
Any clue on the Broken pipe?

[jpic]

No clue about the broken pipe, is this on the development server only or in production servers (gunicorn or uwsgi ?).

I don't think we do any error handling:

https://django-autocomplete-light.readthedocs.org/en/v2/_static/widget.html
https://django-autocomplete-light.readthedocs.org/en/v2/_static/autocomplete.html

But you could override a method like yourlabs.Autocomplete.prototype.makeXhr:
https://django-autocomplete-light.readthedocs.org/en/v2/script.html#override-autocomplete-js-methods

[brycenesbitt]

This happens both in production and development.
It was not noticed until the global ajaxError was added to the project.
In development the server is django, in production it is nignx.

Note that jqXHR.status is always zero. This error is the ajax call death after the connection dies. It happens only with autocomplete. See:

2014/06/08 21:06:20 [info] 31569#0: *17644886 client prematurely closed connection, so upstream connection is closed too while sending request to upstream,
client: 70.36.136.61, server: obviously.com, request: "GET /ac/?q=asdfk HTTP/1.1",
upstream: "http://127.0.0.1:19198/ac/?q=asdfk", host: "obviously.com", referrer: "http://obviously.com/"

or

2014/06/08 21:31:23 [info] 31569#0: *17661567 client 70.36.136.61 closed keepalive connection

[jpic]

Well autocomplete.js does abort a number of requests on purpose:

https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/static/autocomplete_light/autocomplete.js#L551

Maybe that's what you're talking about ?

[brycenesbitt]

Quite possibly. Though the effect is seen both during heavy typing and during slow typing.

I've modified my global error handler to try and ignore connection closed, but it's crude:

$(document).ajaxError(function (e, jqXHR) {
  // Try and avoid alerting on connection closed, which seems to return status code 0.
  // Connection closed seems endemic on autocomplete light ajax calls
  if (jqXHR.status) {
    alert('An error has occurred. If the problem persists after reloading the page, please report to the site administrators. (Code ' + jqXHR.status + ')');
  }
});

[jpic]

I'd love to be able to reproduce this !!

[jpic]

Did you check if throttling is working correctly on the client side ? thanks B)

[jpic]

There's an accepted answer on the stackoverflow: http://stackoverflow.com/questions/7436195/disabling-some-jquery-global-ajax-event-handlers-for-a-request/7436344#7436344

Closing.

[brycenesbitt]

That answer is about ignoring the error... rather than preventing the error.
But I'm no longer working on that project so can't comment if it's still happening.

[jpic]

The issue is about reporting an error with your specific infrastructure .. rather than provide steps to reproduce it or a test case.

Please reopen when you're able and willing to provide more detail.

[jpic]

I've opened a followup issue on the new repo for the JS: yourlabs/jquery-autocomplete-light#3

IMHO, there is no way no one can do anything about it, but just in case I'm leaving it open cuntil the repo is too polluted with issues which we can't do anything about.

IMHO, it's an HTTP request that autocomplete.js made but canceled in favor of a newer HTTP request. With proper server configuration I don't think this would happen but really, I can't reproduce so I wonder @brycenesbitt could let me know what he'd recommend we do about it.

Thanks for the detailed report and helpful attempt to help.

[jpic]

Sincerely I closed it because I've been through it many times while triaging and always came to the same conclusion: not enough detail, can't reproduce the user was focused on working around this in his error handler rather than trying to contribute a proper fix.

You should understand that we're several volunteers going through the issue list and every time there's an issue that's not fixable (not enough detail, not reproducible, user didn't really care to help us) then it's time the volunteer could have used on a fixable issue (detailed, reproducible, with helpful user feedback).

As far as I'm concerned we don't even have proof there's a bug in autocomplete-light here. This might be just a throttling setting in the JS which should be increased to not break under-sized servers. Who can tell really. Anyway, it's time for me to move on to issues which can potentially be reproduced, tested and fixed.

All I can say for now is that the JS has been extracted as a standalone jQuery plugin and maybe someone in the JS community will be able to fix something related.

I hope these explanations are sufficient for your understanding and that you will post what you think I should have done instead of that.

Have a good day

[blueyed]

Have a good day

Same for you! :)

[jpic]

Having a great time at the conference, you should be there bro !!