Yes. it is safe to ignore, but it still causes a minor slow down because web2py issues a ticket and that may be unnecessary.
On May 10, 12:01 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > So you are saying that a user with a slow connection (which consists > of a large portion of the sites user base) clicks reload, so their > browser stops communicating with that request, so web2py catches it as > an IOError... so then is this safe to ignore? > > Below is a log that I found in apache2.error.log > > [Sun Jan 31 13:42:50 2010] [error] [client ******] (70007)The timeout > specified has expired: mod_wsgi (pid=3961): Unable to get bucket > brigade for request., referer:http://mysite.com/page1 > [Sun Jan 31 13:42:51 2010] [error] [client ******] mod_wsgi > (pid=3926): Exception occurred processing WSGI script > '/web2py/wsgihandler.py'. > [Sun Jan 31 13:42:51 2010] [error] [client ******] IOError: failed to write > data > > -- > Thadeus > > On Sun, May 9, 2010 at 11:52 PM, Graham Dumpleton > > <graham.dumple...@gmail.com> wrote: > > > On May 10, 1:51 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > >> Ticket. I usually see them the next day when I check admin. > > >> No, it is usually just one IP but it happens to a lot of people at the > >> same time, scaled by the amount of traffic being put on the server. > > > Then it is likely that the ISP or network all the requests were routed > > by dropped all the connections for whatever reason. > > >> Roughly about 10% of the requests generate this error. > > >> > A user not waiting for a request to complete before clicking on > >> > another link or pressing reload. In other words, client dropped > >> > original connection. > > >> Obviously this is a web2py issue then, because I don't have any > >> problems when I go click-happy on other web sites. > > > Part of the problem is that there is no standard for what type of > > Python exception is generated by a dropped connection. The mod_python > > and mod_wsgi package so happens to use IOError, but different > > descriptions. Other WSGI servers are within their rights to use a > > completely different Python exception or yet another description > > against an IOError. Thus, it becomes really hard for a generic > > framework that can be hosted in various ways to make a judgement as to > > whether a failure on read was due to a particular type of error. Thus > > it becomes hard to ignore errors for loss of connection. You also by > > ignoring them, limit an applications ability to take some special > > action when connections are dropped. > > > It therefore isn't obvious what to do and most Python frameworks will > > as a result just pass the exception up the stack and cause a 500 > > response. If you have a mailout option for errors back to system > > administrators then you obviously may get an lot of emails. Best you > > might do is for that mailout middleware to allow a user to supply > > their own rules, ie., exception types and desription regex, for things > > that should be ignored as far as mailout message to admin. > > > Graham > > >> On Sun, May 9, 2010 at 9:55 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > >> > ure about the problem but I had a few instances of people > >> > clicking reload a lot (and I mean a lot). So I use thi
