A smarter approach could be not generate a ticket if the socket is closed but I think still Graham objection would still be valid.
On May 10, 6:51 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > There are alot of these tickets being generated, roughly 10%, this is > annoying from a prospective of attempting to determine the tickets > that are real! Let alone the amount of files it is placing in the > errors folder quickly exceeds the recommended max file count for a > folder. > > I wish it would at least not generate a ticket. However, it might come > down to needing a cron script that will clean up any tickets that > contain IOError. > > -- > Thadeus > > On Mon, May 10, 2010 at 6:06 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > Good point. I guess I would revert the latest change to wsgibase() > > let me me think about this some more. > > > On May 10, 5:48 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > >> On May 10, 3:01 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > >> > Graham is right. The best we can do is catch > > >> > try: > >> > data = src.read(size) > >> > except: > >> > raise MySocketException > > >> > and catch it later as I suggested above. What do you think? > > >> You can't technically do either of the things you have suggested, ie., > >> catch all or catch just IOError. In WSGI you might not be reading > >> direct from the original wsgi.input but from a WSGI middleware. It may > >> introduce its own sort of IOError for totally different reasons and > >> may raise exceptions for other reasons. If you blindly catch all > >> exceptions or even just of type IOError, you may mask totally > >> unrelated errors and make it extremely difficult for people to debug > >> things. > > >> As I said in my original post, the best you can do is to propagate up > >> the original exception, but have any system which catches uncaught > >> exceptions and mails out details be able to be configured by a user > >> (not by default), such that the user can specify exception types and > >> exception descriptions which can be ignored for the particular hosting > >> system or combination of WSGI middleware they use. > > >> Graham > > >> > Massimo > > >> > On May 9, 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
