RE: [Zope] Problem with running same script at a time
Thank you Dieter! Here is the exact scenario, which in I first observed the problem: I have a external zope python module that communicates via TCP with a background system written in Java. I have a background system that communicates with the Zope via URL. I have a demo user folder in my Zope project with two scripts. The first script sends a tcp message to the background (with the help of external module), the second one do something when the background call it via url. First the Zope script sends a tcp message to background system, and waits for the reply. The background receives the message and try to call the url by http request, then if it is success replies to Zope script's tcp request. Here is the problem. The background system cannot access the URL until in the first script tcp timeout happen. When I move the second script into other outer folder, all is OK. It is very strange, and I'v never read from this problem before. Best regards, Antal -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: Thursday, September 21, 2006 7:46 PM To: Pletli Antal Cc: zope@zope.org Subject: RE: [Zope] Problem with running same script at a time Pletli Antal wrote at 2006-9-21 09:12 +0200:
... I use the same product. This problem is one of the others...
I had to fix a problem in "psycopg": During "connect", Python's Global Interpreter Lock (GIL) was not released (freezing Zope during connect). Usually, this is not a problem as "connect" is quite a fast operation. We noticed it only when the server for the postgres installation was down (then "connect" became a several minute operation until the TCP timeout happened). However, it is unlikely, that this is your problem.
The behaviour is the same when i use long socket communication (as a tcp client), etc.
This, too, should not happen -- and I never observed it (but a colleague reported something like this but never showed it to me -- and I did not believe him; or more precisly, I tested his alledgedly observed behaviour and could not reproduce it...)
In these cases the folder wich contains the scripts be unaccessible.
Unbelievable -- unless your folder access triggers the long socket communication. In this case, it would not be the old socket communication that "blocks" but the new one. Of course, your folder access should not trigger anything else... -- Dieter
Pletli Antal wrote:
When I move the second script into other outer folder, all is OK.
It is very strange, and I'v never read from this problem before.
Eh? You've never heard of a blocking problem before? You're creating a blocking loop, which you seem to have now fixed... nothing odd about that... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Pletli Antal wrote at 2006-9-22 08:51 +0200:
... I have a demo user folder in my Zope project with two scripts. The first script sends a tcp message to the background (with the help of external module), the second one do something when the background call it via url.
The problem is your setup. I have to explain a bit that you can understand the problem. Zope's request processing has roughly two phases: URL traversal to locate the object identified by the URL and then calling the located object. At the end of URL traversal lies the user authentication. This proceeds as follows: Zope starts at the located object and looks upward (towards to root) to find a User Folder which is ready to authenticate the user with the required roles. It will ask each User Folder it finds above the object until one gives a positive answer. The highest user folder will always return a user, maybe the anonymous one. If your User Folder calls out to a backend system and this backend system calls back (via URL) into an area controlled by your User Folder, then you lose -- as the User Folder will again call out and wait for an answer before it will call the object... Move the thing called back out of your hiararchy dominated by the UserFolder. Then, you might have success. -- Dieter
participants (3)
-
Chris Withers -
Dieter Maurer -
Pletli Antal