[Zope3-Users] zc.async in Zope2/Plone

[Gary Poster]

On Sep 12, 2008, at 1:23 AM, Santiago Videla wrote:

> Well, after some hours and many buildouts done, I couldn't get this  
> running.
>
> The best approach I got is like this (using repoze.plone):
> 1) just run the standard buildout.cfg for repoze.plone
> 2) add zc.async to the eggs section in the buildout and run again.
> It's important to add the egg here, when I added just to the extra- 
> requirements in the setup.py of my egg, it doesn't work. Something  
> about IOBTree.family32 it's raised... sorry, I didn't copy the  
> traceback
> 3) Here, the instance starts, but tests won't work. I had to edit  
> the test script, to move down the import of zope.testing. after  
> that, tests are running. Obviously, running the buildout again, will  
> overwrite this change
>
> I will try to keep working on this, but I have to move on these days

Understood.  It's a good start.  Thanks for the report!

> Now, a question about the usage of zc.async, I followed the docs in  
> the QUICKSTART txt
> In my egg I have this
>
> __init__.py
> =================
> import ZEO.ClientStorage
> import ZODB
> import zc.async.configure
>
> storage = ZEO.ClientStorage.ClientStorage(
>                                 ('127.0.0.1', 8881),
>                                 name='zeostorage',
>                                 )
> db = ZODB.DB(storage, database_name='main')
> zc.async.configure.base()
> zc.async.configure.start(db, poll_interval=1)


This is reasonable.

This pattern is typical for a stand-alone zc.async instance.  This  
will run the dispatcher in a thread.  The next version (1.5) has an  
argument to ``start`` to have the dispatcher run in the main thread,  
if you'd prefer.

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?

> =====================
>
> some_handlers.py
> =====================
> import zc.async.interfaces
>
> def async_job():

 From your use of ``Job`` below, I suspect this takes a single  
argument, ``portal``, in the real code.

>
>     ....
>     do something
>
> def some_job(context):
>     urltool = getToolByName(context, "portal_url")
>     portal = urltool.getPortalObject()
>
>     #portal._p_jar give us the connection to the ZODB
>     queue = zc.async.interfaces.IQueue(portal._p_jar)

This is fine, but I wonder if you have to add the _p_jar...

Maybe for this upcoming version I just added the registration to adapt  
a persistent object, in addition to a connection?  Not sure offhand,  
and I have to run.  I'd expect this to not require the _p_jar: ``queue  
= zc.async.interfaces.IQueue(portal)``

>
>     job = queue.put(zc.async.job.Job(
>                                async_job,
>                                portal.aq_base)
>     )

If you're not going to do anything further with the job, then you  
could just leave out ``job =``, of course.

>
> ======================
>
> This code it's running and it works, but I'm not sure if it's the  
> correct usage... Gary?

Looks fine. :-)

If you discover that you are doing the same Zope2-specific (or Plone- 
specific) setup/teardown for all your jobs, notice that you can have a  
Job subclass that defines setUp and tearDown.  See what z3.py does,  
for instance.

>
>
> Last question, when I run my test, I'm getting this error
>
> 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.)

>
>
> I was reading ftesting.txt from zc.async but I yet don't understand  
> what should I do, any hints?
>
> best regards
>
> On Thu, Sep 11, 2008 at 5:51 PM, Michael Dunstan <michael.dunstan at gmail.com 
> > wrote:
> On Fri, Sep 12, 2008 at 5:02 AM, Santiago Videla
> <santiago.videla at gmail.com> wrote:
> > Hi guys,
> >
> >>>
> >>> z3c.recipe.fakezope2eggs lets you tame these kind of  
> dependencies. See
> >>> http://pypi.python.org/pypi/z3c.recipe.fakezope2eggs
> >>>
> >>> plone.recipe.zope2install includes a couple of options for  
> making use
> >>> of that too. See http://pypi.python.org/pypi/plone.recipe.zope2install
> >
> >
> > Nice, I will try those.
> >
> > But I have another issue... :(
> > I need to use repoze.plone and I don't have any zope2 section in my
> > buildout.cfg (needed to use fakezope2eggs). I need to find a way  
> to tell to
> > fakezope2eggs where is the python/lib/zope directory
>
> I think you should be able to do that by declaring a zope2-location
> for the z3c.recipe.fakezope2eggs part.
>
> [fakezope2eggs]
> recipe = z3c.recipe.fakezope2eggs
> zope2-location = ...
>
> where ... points to your python directory of python/lib/zope
>
> --
> Michael Dunstan
>
>
>
> -- 
> Santiago Videla
> www.revolucionesweb.com.ar
> http://www.linkedin.com/in/svidela
>
> Sigue la mata dando de que hablar siempre abajo y a la izquierda  
> donde el pensamiento que se hace corazón resplandece con la palabra  
> sencilla y humilde que l at s tod at s somos.