Hi, I currently use the Python urllib module to write small Python scripts which, launched via cron, access my Zope web site nightly to execute administration tasks (which can't be done throught wget). My problem is that some of these tasks (like database packing) are now very long and I never see their output, even if the task is executed correctly. I suppose that this is because of a timeout in the "FancyURLopener" subclass I use. So : - am I right ? - how can I avoid this (without using wget ?) ? Does the "REQUEST.RESPONSE.write()" method can be used for that ?? Thanks for any help, Thierry -- Linux every day, keeps Dr Watson away... http://gpc.sourceforge.net -- http://www.ulthar.net
Hi Florac, FLORAC Thierry schrieb:
Hi,
I currently use the Python urllib module to write small Python scripts which, launched via cron, access my Zope web site nightly to execute administration tasks (which can't be done throught wget).
why not? Its possible, although the urllib variant isnt that bad either.
My problem is that some of these tasks (like database packing) are now very long and I never see their output, even if the task is executed correctly. I suppose that this is because of a timeout in the "FancyURLopener" subclass I use.
You schould go for ZEO since this makes packing asynchronous, giving you immediate result for the urllib call. I'm not aware of any timeout in urllib and at least you should get an exception, not nothing at all. If in doubt, run a sniffer/logger for the network traffic in parallel, for example tcpflow. The ZEO approach also leads to another interesting posibility: you can call the methods with a 2nd client directly. Just mount the ZODB from your "cron" script. Regards Tino Wildenhain
On Tue, 3 Feb 2004, Tino Wildenhain wrote: [...]
I'm not aware of any timeout in urllib and at least you should get an exception, not nothing at all. If in doubt, run a sniffer/logger for the network traffic in parallel, for example tcpflow. [...]
If you're using Zope 2.7 with Python 2.3, maybe something is calling socket.setdefaulttimeout(), and then something else catches the socket.timeout exception?? Sounds unlikely, though... Take Tino's advice about the sniffer. John
participants (3)
-
FLORAC Thierry -
John J Lee -
Tino Wildenhain