Yes - I still have all the emails from the cherrypy folks w/ suggestions, and the (really nasty) spreadsheet tracking the packet exchanges between cherrypy and a particular browser engine...
I don't know when I'd be able to try to look at this again. If someone wants to debug packets w/ wireshark, and dig in let me know.... btw - it only happens with bigger transfers, and then only with some archves... e.g. w/ 1.65.4, it might have disappeared again for a while... (although I think Massimo would be willing to put the last archives showing the problem somewhere for test / debugging purposes) On Wed, Jul 15, 2009 at 2:52 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > There is a known timeout problem with the version of wsgiserver that > we include in web2py. Newer version seem to have even more problems. > We never quite got to the bottom of that. The problem does not appear > in a typical production environment if you use mod_wsgi and thus > bypass wsgiserver. > > It would be nice to get to the bottom of this. > > Massimo > > On Jul 15, 2:35 pm, rb <rbspg...@gmail.com> wrote: > > I don't know if this is related, but it sounds similar to a problem I > > was having (Web2py 1.65.1). > > > > I wrote a C++ program to bootstrap my thick-client deployment. The > > user would download the C++ program from the static file on the > > server. The program downloads another static file which contains a > > list of files, with version information. It then compares it's > > versions with the server's list and downloads the new files. > > > > In this list I have several folder trees under the root of 'img'. Each > > folder name gives the thick-client info on the img (ie. "Setup", Setup/ > > Company", etc) and in the bottom-most folder would be the img file > > (e.g. "img.bmp"). To start with I just used copies of the same img > > file "img.bmp" in all of the subfolders as a placeholder for the > > correct imgs to come later. > > > > For some odd reason I would get the first instance of img.bmp > > downloaded correctly, but later instances would either not come down > > at all or else I'd get a partial file. The code logic never indicated > > any error. The logic would complete the download when it received 0 > > bytes from the server, (and with no transmission error - these would > > get caught). > > > > I assumed that this problem has something to do with server-side > > caching and worked around it / avoided it by using a 0 length > > "img.bmp" file at the bottom of the folder tree and inserting one more > > level of folder where that folder would be the name of an img file > > kept elsewhere. That way, I'd only have to download one instance of > > the bmp file. This seems to work. > > > > Here's an example of the folder trees: > > > > "imgs/Setup/Company/BlankDocument-72x72.bmp/img.bmp" > > "imgs/Setup/Users/BlankDocument-72x72.bmp/img.bmp" > > > > Thus I only needed one copy of the BlankDocument-72x72.bmp file and > > could reference it for my images for the list as many times as I > > wished. > > > > So... could there be a problem with Web2py's caching of files to > > download? My program uses Microsoft Win32 API calls: > > > > InternetOpen() > > InternetOpenUrl() > > InternetReadFile() > http://msdn.microsoft.com/en-us/library/aa385103%28VS.85%29.aspx > > > > I thought the problem could be my own code (*probably is*), but it > > fails only when downloading multiple copies of the same file. Of > > course the problem could be something like file permissions, etc. I > > mention this only because it sounds suspiciously like the other > > complaints above. > > > > -- > > Rb. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
