In trunk, give it a try.
On May 10, 2:32 pm, Thadeus <[email protected]> wrote: > As soon as you post the fix I will update the web2py version and keep > an ear out if anyone has any connectivity issues. > > Thanks. > > On May 10, 9:35 am, Thadeus Burgess <[email protected]> wrote: > > > My original concerns are eased, as I thought 120 people out of the > > 1000 that visited the site were getting errors [1], which seems to not > > be the case. > > > If I were to go to all of the trouble to install nginx, I might as > > well stop using apache and install cherokee. I have been running my > > blog on cherokee with no problems. > > > Massimo, looks reasonable... we can always change it later. > > > [1] the requests are unique visits, no robots included > > > -- > > Thadeus > > > On Mon, May 10, 2010 at 1:53 AM, Graham Dumpleton > > > <[email protected]> wrote: > > > > On May 10, 3:11 pm, Thadeus Burgess <[email protected]> wrote: > > >> Looking at the sites analytics, there are roughly about 1000 requests > > >> a day, of which I will receive 100 of these tickets, give or take 20. > > > > If you want a quick solution, stick nginx in front as a proxy and you > > > likely would eliminate the errors. This is because nginx helps to > > > isolate you from slow clients and some of the problems they can cause. > > > You can also offload static file serving to nginx as well, speeding > > > that up and allowing you to use less resources in Apache to serve same > > > number of requests. > > > > I'll comment later when have time on Massimo's comments. > > > > Graham > > > >> On Mon, May 10, 2010 at 12:10 AM, Thadeus Burgess > > >> <[email protected]> wrote: > > >> > What if there was an IO error with cgi.FieldStorage ? > > > >> > -- > > >> > Thadeus > > > >> > On Mon, May 10, 2010 at 12:06 AM, mdipierro <[email protected]> > > >> > wrote: > > >> >> 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 <[email protected]> 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 > > > >> >>> <[email protected]> wrote: > > > >> >>> > On May 10, 1:51 pm, Thadeus Burgess <[email protected]> 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 > > >> >>> >> <[email protected]> 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
