[infinispan-dev] ispn + quartz

Romain Pelisse belaran at gmail.com
Thu Mar 27 08:39:00 EDT 2014


Hi Bela,

I said the idea is to limit the configuration stuff to ISPN. Before this
change, the clustering of the application required JMS queue to be
clustered, along with Quartz. The JMS Queue was misused to trigger a cache
invalidation, so I removed this complexity by simply replicate the cache.

Once this was done, I realized, I could misused a bit ISPN to also remove
the need for Quartz sync. I'm pretty sure ISPN is not the best tool for the
work (task sync) but it is the best to reduce the complexity (in this use
case) :)

That being said, this task distribution feature of JGroups is pretty
awesome, I'm quite happy to have heard about it :)

PS: I though of you last Tuesday - I, again, went to a customer and remove
cluster from their EAP configuration :)


On 26 March 2014 17:16, Bela Ban <bban at redhat.com> wrote:

> Romain,
>
> do you really need Infinispan to do that ? Look at [1], IMO it's much
> more elegant... :-)
>
> [1] http://www.jgroups.org/taskdistribution.html
>
> On 26/03/14 16:54, Romain Pelisse wrote:
> > Well, my requirement is exactly the same ! Just that one node (and not
> > all of them) runs a task. So instead of setting up Quartz clustering, we
> > let the Seam/Quartz scheduling fire up task on each node, but the "first
> > node" to get there locks some cache (which is replicated sync. with
> > pessimistic locking), so that the other ones cannot acquire the lock.
> >
> > It's not that elegant, but this remove the need of clustering quartz and
> > make the needs for configuration to the bare minimal (more/less just
> > ispn inside wildfly needs to be configured). The difference between a
> > test env and a pre prod and prod env is only that ISPN is distributed
> > (and the mentioned cache replicated).
> >
> > Implementation wide, I think the customer end up having a static method
> > being call on all Quartz classes, but I guess this could be placed in
> > somekind of interceptor.
> >
> > I can ask the developer involved at the customer to discuss this with
> > you if you want.
> >
> >
> >
> > On 26 March 2014 13:35, Ales Justin <ales.justin at gmail.com
> > <mailto:ales.justin at gmail.com>> wrote:
> >
> >>     I'm not bridging Quartz with ISPN, I'm currently using ISPN to
> >>     synchronise Quartz task (instead of clustering Quartz), mostly to
> >>     simplify a customer app (ie just need to tweak the ISPN cluster,
> >>     nothing else).
> >
> >     How do you do that?
> >     By executing a job on entry eviction?
> >
> >>     Out of curiosity, can you comment a bit about why/how you want to
> >>     bridge Quartz with ISPN ?
> >
> >     Wrt how, no idea yet. :-)
> >     It's been a while since I used Quartz.
> >
> >     My requirement is to have a single job per trigger execution across
> >     all nodes.
> >     e.g. only one node should handle particular job
> >
> >     -Ales
> >
> >>     On 26 March 2014 12:25, Ales Justin <ales.justin at gmail.com
> >>     <mailto:ales.justin at gmail.com>> wrote:
> >>
> >>         Was there ever any attempt to bridge Infinispan and Quartz?
> >>         * http://quartz-scheduler.org/documentation/faq#FAQ-clustering
> >>
> >>         As I'll probably need it for this:
> >>         * https://developers.google.com/appengine/docs/java/config/cron
> >>
> >>         If nothing exists, I'll have a crack at it.
> >>
> >>         -Ales
> >>
> >>
> >>         _______________________________________________
> >>         infinispan-dev mailing list
> >>         infinispan-dev at lists.jboss.org
> >>         <mailto:infinispan-dev at lists.jboss.org>
> >>         https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >>
> >>
> >>
> >>     --
> >>     Romain PELISSE,
> >>     /"The trouble with having an open mind, of course, is that people
> >>     will insist on coming along and trying to put things in it" --
> >>     Terry Pratchett/
> >>     Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/>
> >>      (... finally up and running !)
> >>     _______________________________________________
> >>     infinispan-dev mailing list
> >>     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> >
> > --
> > Romain PELISSE,
> > /"The trouble with having an open mind, of course, is that people will
> > insist on coming along and trying to put things in it" -- Terry
> Pratchett/
> > Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/>     (...
> > finally up and running !)
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



-- 
Romain PELISSE,
*"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it" -- Terry Pratchett*
Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/>     (...
finally up and running !)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140327/f7c1b990/attachment.html 


More information about the infinispan-dev mailing list