is there any body working on plone.app.async compatible with plone5
As far a I know, the most up-to-date async solution at the moment is collective.celery https://github.com/collective/collective.celery
It does work on Plone 5.
does it work with collective.documentviewer?
Sorry, no idea what the state of plone.app.async is.
Alternatively collective.zamqp (PyPI, GitHub) tests are passing on Travis for Plone 5
I roughly looked over plone.app.async, looks fine, even if last change was 2012 - what exact is the problem you got with Plone 5?
Considering this commit message: https://github.com/collective/collective.documentviewer/commit/c261d8aff26b95336bbb3bf7a41ffd2ccd355f75
I guess collective.celery and collective.documentviewer do work together.
Maybe @vangheem can tell us more about it?
There's also ploneintranet.async which uses Redis instead of the ZODB to store the queue. You can use that as a standalone package without loading the whole ploneintranet stack.
https://docs.ploneintranet.org/development/components/async.html
BTW I wrote ploneintranet.async on Plone5 for async document view rendering
@gyst fwiw, celery doesn't store anything in the zodb either and can be configured with redis, rabbit, etc.
@rnunez document viewer should work with collective.celery.
I was using p.a.async and for different random errors (together with collective.cron) I end up replacing it with collective.taskqueue (also using redis to store queues) and plain old unix cron.
So far so good, with minor glitches as expected.
Any else think its not fun to have no standard plone api for async so your plugin works with anyone of these rather than just one or two?
As in, we have enough examples by now to create a api each of these implementations could implement and put the api in the core with no default implementation (or a really basic one). or are they too different?
I currently have to use two different queues (plone.app.async and c.taskqueue) just because different plugins choose a different queue plugin.
I totally agree, this situation is not good.
My personnal feeling is that if there are so many solutions for the same thing, that's probably because none of those solutions is fully satisfying.
So it is probably difficult to build the right solution. Nevertheless we should try.
Agreed. We should have one pluggable solution that has an defined API and works with several backends like Celery, AMQP, and so on...
ZCA time! Simplest would be to agree on an common Interface and provide it in Plone together with some basic, non-activated Zope-only implementation together with a non-async implementation for testing purposes. Addons with async needs then can query a utility implementing the interface. Done. Other addons for Celery or AMQP (...) are providing this interface.
1 Like
collective.taskqueue definitely works best of all task queue solutions.
Thinks missing: queue introspecting.
Andreas
1 Like
Be it c.taskqueue (which I'm a great fan of) or not, it's API simplicity is really nice.
Actually by default, without any extras it already works locally, so for small throw away things is working out of the box.
It has redis support as well and probably celery and so on would not be that much away.
@datakurre probably can tell us more about it.
1 Like
We don't have to pick one. We could just have have an interface/api in the core. Similar to odbc or portlets.
That would mean the api would be the most set of functions that everyone could support. But thats better than having to choose. If you want to bypass the api you could to get more functionality.
I have enough async solutions for myself, so everything I say and do around this topic should be taken with grain of salt 
At least collective.taskqueue and ploneintranet.async have quite similar APIs and it should be possible to design a core API, which is adaptable to both.
ploneintranet.async is obviously cleaner and better designed than collective.taskqueue, but collective.taskqueue is the only one, providing async using Zope2's built-in asyncore, without external services.
On the other hand, celery, required by ploneintranet.async, provides features missing in collective.taskqueue. But that's by design. At some point, I'm going to add RabbitMQ queue type for c.taskqueue (still waiting for rabbitpy to stabilize), and that's why I'm not going to duplicate RabbitMQ's observing features in c.taskqueue (at least by myself).
If I ever get to work with some ploneintranet based solution, it's also possible to a such plugin for collective.taskqueue (a new "queue type"), which allows collective.taskqueue to use ploneintranet.async as queue backend.
@rnunez If this is the problem you're referring to: https://github.com/plone/plone.app.async/issues/6
I just committed a new version that explicitly defines the zope.minmax dependency. Not sure if everything else works though. For me, it installed fine on Plone 5. Maybe you have some older dependencies in pinned for the other dependent packages?
Thanks Nathan, version 1.7dev0 did work, I'll do more testing in the upcoming days.
Thanks all for the great Idea/work, I'll stick with p.a.async for this upgrade