I am going to leave this entire thread since it is a good synopsis of my issue and results to date. End of top post ... continued in bottom post.
On Friday 13 October 2006 12:25 am, boblq wrote: > On Friday 13 October 2006 12:02 am, James G. Sack (jim) wrote: > > boblq wrote: > > > Hi Guys, > > > > > > Could not make the main meeting tonight :( > > > > > > But here is a puzzler. > > > > > > > > > On Server 1 > > > I have a simple HTML forms file > > > that invokes a php program that > > > writes the values input into the form > > > into a simple text file and then > > > redirects to tat text file thus displaying it. > > > > > > This works fine. I surf in from Client 1 > > > fill in some values hit Submit and see > > > them displayed. > > > > > > So far so good. > > > > > > But I actually want to pull those down on > > > another box, lets call it Client 2, for use > > > in another program. If use wget to grab > > > the file written by the previous process > > > all is well. I can go back to my form on > > > Client 1 and repeat the entire sequence. > > > > > > Now though I want to replace wget with > > > a simple Python program. So I write > > > pget.py > > > > > > #!/usr/bin/python > > > > > > from urllib import urlopen > > > > > > call_url = "http://some_server/some_dir/test.txt"; > > > u = urlopen(call_url) > > > doc = u.reaad() > > > u.close() > > > print doc > > > > > > Now this little pget.py works fine and grabs the > > > file just like wget. Except there is a problem. > > > Now when I go back to Client 1 and try to > > > enter new values the Client hangs for a long > > > time upon hitting Submit, ie. maybe a minute > > > or more (I have not actually timed it.) > > > > > > Color me puzzled. I am not even sure how > > > to debug it. > > > > > > Both Client 1 and Client 2 are behind a > > > Linksys router and access Server 1 > > > through a cable modem and the Internet. > > > I don't think that is the problem though ... > > > after all wget does not cause this issue. > > > > > > Anybody have a clue? Or a suggestion as to > > > how to proceed? I really don't want to be > > > reduced to packet sniffing. > > > > The behavior looks like the close() isn't working. > > > > Ahhh.., try > > ./pget.py;netstat -anto > > and look for an open connection with a 60s timer counting down. > > It takes about 90 seconds, which definitely sounds > like a timeout. > > > I find that code just like yours leaves (I believe) half-open sockets > > with or without the close. Maybe that's locking the server-end? > > Yeh, that makes sense. It has to be some kind of > a problem like that. > > > But I find that urllib2 works even without an explicit close. You might > > try using urllib2 instead of urllib if you have/can get it on your > > system. If not, it would be a bit painful to drill into the urllib code > > to fix the socket.close() interface. > > > > More ahhh.., I see that urllib2.close is actually a dummy function -- so > > maybe that further suggests a bugfix between urllib and urllib2. > > > > (I've kinda-remember seeing other disparaging remarks about urllib and > > preferences for urllib2). > > > > Regards, > > ..jim > > OK, I will try urllib2 tomorrow. Well later today. I am a > bit too tired for now. I will post my results. > > Thanks for the suggestions, > > BobLQ Ok, this morning I tried urlib2. It works in terms of getting the file ... but it has the same problem. Since wget works fine I suspect that the Python urllib is somehow broken. As Jim suggested the problem may well be an unclosed socket (or half socket.) I will do some research to see if this is a known issue. This seems to me to be a serious bug if in fact it is a bug. The server is only hung for the Client 1. Repeated runs of pget.py from Client 2 go just fine. One further test that points toward the urllib (or urllib2). I wrote a Python wrapper around wget. Just #!/usr/bin/python import os os.system("wget http://some_server/some_dir/test.txt";) This works fine. I suppose I can use a variant on this theme to solve my specific problem ... but I am _not_ a happy camper. If this is a bug in Python and not in BobLQ's usage then one would think it well known. I guess it is time to hunt up the Python bug base and see. Any further suggestions? BobLQ BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
