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 [EMAIL PROTECTED]
wrote:
On Fri, Sep 12, 2008 at 5:02 AM, Santiago Videla
[EMAIL PROTECTED] 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 =
