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 -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
