How to develope a ZObject to connect to an socket server?
Hi all! I'm trying to develope a zope object that connects to a external socket server in order to comunícate with it and receive some events (Maybe I need a thread to process events). The problem is how to establish the connection at the start of zope and to disconnect at the end. After some test assigning the socket server object to _v_ variables in the zope object, it missed the connection after a while. It seems that it can't maintain the reference stored in the _v_ variable. I thing that the behaviour is something like database connections and I'm looking into some database connection objects to find out the mechanism used. If anybody has interesting information or knows where to achieve docs about this, please could you advise me? Juan Carlos Coruña jcc@ibdosnorte.com
On Thursday 22 August 2002 09:04 am, Juan Carlos CORUÑA wrote:
Hi all!
I'm trying to develope a zope object that connects to a external socket server in order to comunícate with it and receive some events (Maybe I need a thread to process events).
That's probably a good idea if not necessary if Zope must respond to incoming events other than over HTTP.
The problem is how to establish the connection at the start of zope and to disconnect at the end. After some test assigning the socket server object to _v_ variables in the zope object, it missed the connection after a while. It seems that it can't maintain the reference stored in the _v_ variable.
I would recommend using module level global variables instead. Volatile vars are just that. If a persistent object with volatiles gets unloaded by the ZODB (which can happen at any time arbitrarily), its volatiles go bye bye. Volatiles are also thread specific. Module globals are shared across threads, which may be a good or bad thing depending on your situation ;^).
I thing that the behaviour is something like database connections and I'm looking into some database connection objects to find out the mechanism used.
Yup. Except they don't receive events except in response to a request coming from Zope. -Casey
On Thu, 2002-08-22 at 10:47, Casey Duncan wrote:
On Thursday 22 August 2002 09:04 am, Juan Carlos CORUÑA wrote:
Hi all!
I'm trying to develope a zope object that connects to a external socket server in order to comunícate with it and receive some events (Maybe I need a thread to process events).
That's probably a good idea if not necessary if Zope must respond to incoming events other than over HTTP.
The problem is how to establish the connection at the start of zope and to disconnect at the end. After some test assigning the socket server object to _v_ variables in the zope object, it missed the connection after a while. It seems that it can't maintain the reference stored in the _v_ variable.
I would recommend using module level global variables instead.
And you can initialize them on the module body, which means it will run only one time, either at Zope init or at the first time the module is imported. Disconnecting at the end could be a problem though. I don't know of a reliable way to know when Zope is going to shut down because it could be stopped from the command line (./stop) where the Zope process will just be killed. Maybe you can plug into the new Zope signal handling stuff.
Volatile vars are just that. If a persistent object with volatiles gets unloaded by the ZODB (which can happen at any time arbitrarily), its volatiles go bye bye.
Volatiles are also thread specific.
Which means that, with Zope's default 4 (I think) worker threads, you can get as much as 4 simultaneous open connections (Yes, most database adapters do that on purpose).
Module globals are shared across threads, which may be a good or bad thing depending on your situation ;^).
But at least they're unique within Zope.
I thing that the behaviour is something like database connections and I'm looking into some database connection objects to find out the mechanism used.
Yup. Except they don't receive events except in response to a request coming from Zope.
Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
participants (3)
-
Casey Duncan -
Juan Carlos CORUÑA -
Leonardo Rochael Almeida