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. Cool! > > 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 half). http://svn.zope.org/zc.async/trunk/src/zc/async/QUICKSTART_1_VIRTUALENV.txt?rev=90112&view=auto 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: afd1e0d0-52e1-11dd-879b-0017f2c49bdd ------------------------------------------------------------------------ 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 single 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 section of your zdaemon.conf. Supervisor (http://supervisord.org/) also provides this functionality. Other similar tools probably do as well. If the ``ZC_ASYNC_UUID`` is not found in the environment, it will use ``os.path.join(os.getgwd(), 'uuid.txt')`` as the file name. To get a new identifier for this software instance, delete this file, restart Python, and import zc.async.instanceuuid. This file will be 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 quickstart! Thanks Gary _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
