On Sep 12, 2008, at 7:16 PM, Santiago Videla wrote:

> Hi Gary,
> If you want a Zope 2 instance to run the zc.async dispatcher/worker  
> threads, then it might be better to get the DB that zope is using.   
> In Zope 3, there's an event you can subscribe to to get the DB.   
> Maybe there's something similar in Zope 2 these days?
> I found it. but I'm not sure if really fire the event at any moment.
> in my configure.zcml I have:
> <subscriber
>       for="zope.app.appsetup.
> IDatabaseOpenedEvent"
>       handler=".handlers.zcasync_config_handler"
>       />
> the instance starts, but it seems that the handler never run

You explained this in the email today.  Good to know.  That means in  
2.11 the zc.async setup might be extremely close to that of Zope 3.   

> 2008-09-12 02:20:01 ERROR zc.async.events UUID  
> 10c69742-8084-11dd-9853-0016d3094e86 already activated in queue   
> (oid 44148): another process?  (To stop poll attempts in this  
> process, set ``zc.async.dispatcher.get().activated = False``.  To  
> stop polls permanently, don't start a zc.async.dispatcher!)
> Maybe you are running your tests while you are running your app  
> instance, and that both of them actually connect to your real live  
> ZEO.
> Or maybe you are starting a dispatcher yourself, *and*  
> zc.async.ftesting.setUp is starting a dispatcher?  (ftesting setUp  
> does start one.)
> right, and what about running many clients with one ZEO.

Many clients with one ZEO server is just fine, as long as they have  
their own UUID.  This newer version of the quickstart, based on trunk,  
explains the idea (look for the Monte Carlo discussion in the second  


The sphinx-processed version of this file is much easier to read, but  
I don't want to upload that until I have the release that it describes!

> I'm getting the same error and I don't understand what to do, this  
> is why I need to get the DB that zope is using?

No, you don't have to get the same DB.  Just maybe cleaner.

Each dispatcher process needs its own UUID, as saved in uuid.txt, as  
controllable by an environmental variable.  If you hunt around, I bet  
you'll find a uuid.txt, probably in the same directory that you  
usually start your process.  If you read that text, you'll see  
something like this:

     The value above (and this file) is created and used by the zc.async
     package. It is intended to uniquely identify this software  
instance when
     it is used to start a zc.async dispatcher.  This allows multiple
     dispatchers, each in its own software instance, to connect to a  
     database to do work.

     In order to decide where to look for this file (or to create it, if
     necessary), the module looks in ``os.environ['ZC_ASYNC_UUID']``  
for a
     file name.

     If you are using zdaemon (http://pypi.python.org/pypi/zdaemon) to
     daemonize your process, you can set this in a zdaemon environment  
     of your zdaemon.conf. Supervisor (http://supervisord.org/) also  
     this functionality. Other similar tools probably do as well.

     If the ``ZC_ASYNC_UUID`` is not found in the environment, it will  
     ``os.path.join(os.getgwd(), 'uuid.txt')`` as the file name.

     To get a new identifier for this software instance, delete this  
     restart Python, and import zc.async.instanceuuid.  This file will  
     recreated with a new value.

> thanks for your help again, and sorry for my ignorance

Don't apologize!  I've spent a lot of time on docs, but they still are  
far from what I want.  The virtualenv quickstart is good, but I need  
to finish the grok quickstart I have--and then maybe add a Zope 2.11  


Zope3-users mailing list

Reply via email to