The idea is to guarantee that the job is executed. Of course, it may be aborted if there´s a problem in the job itself, but if the server is shut down during the job execution, this job must be automatically retried on the next startup.
[] Leo On Sat, Nov 23, 2013 at 11:33 AM, Romain Manni-Bucau <[email protected]>wrote: > Hi > > It is quite complicated, what's your real goal (not the technical > solution)? It looks like timers + @async would be enough > Le 23 nov. 2013 14:17, "Leonardo K. Shikida" <[email protected]> a écrit : > > > Hi > > > > First of all, I'd like to thank this community for all the help during > > these months. > > > > I've noticed a significant performance/stability improvement from 1.5.2 > to > > 1.6.0. Good job. > > > > I am experiencing some fine tuning issues, so I'd like to ask you for > some > > advice. > > > > My app is simple as that: it's a web app that allows the user to manage > > several timers (quartz). Each time the quartz cron job is triggered, the > > @Timeout method just queues a job (activemq). Then some MDBs consume that > > job (it's a long running job). So producers can be much faster than > > consumers. Both JMS and Quartz are backed by an Oracle XE instance. > > > > JMS messages are very small and must never be ignored or discarded. > > > > One thing I've noticed is that I'll have to control the quartz jobs > myself, > > because even if I pause the timers, when the server is restarted, timers > > are restored and restarted automatically, probably because the JEE spec > > says it must be this way. I am considering the idea of not persisting > > quartz, but only some job metadata, and in the next restart, some EJB > > annotated with @Start can restart or not each timer. > > > > Another thing I've noticed is that when I have 10 quartz jobs that > trigger > > a new job every minute (I was trying every second, but resources were > being > > quickly consumed, although I'd be happy to find some config that could > > allow this in a 8GB RAM machine) would be enough to make my web app not > > responsive, hanging forever. That's why I am asking in another email how > > can I specify different pools for different EJBs. Sounds to me that > > something is really not configured well, because 10 jobs submitting a JMS > > message each second should not be a very big deal I guess. > > > > Since the bottleneck seems to be in the producer side, I've tried to > change > > the producer EJB (that has the @Timeout method) from @Stateless to > > @Singleton+@Lock(LockType.WRITE) but it seems I've just moved one > problem > > from one side to another. > > > > Another thing I've noticed that adding a producerFlowControl="false" to > > activemq.xml could help, but it was not enough. > > > > I've also noticed that consumers work better if I add a Thread.sleep(50) > > before consuming at onMessage(Message msg), maybe giving some time for > JMS > > to release locks (I think). > > > > Last but not least, I've experiencing some strange problems probably > > related to the classloader, and I've removed xerces-impl-2.11.0.jar from > > eclipse factory path (java compiler -> annotation processing -> factory > > path, to generate openJPA metamodel classes for Criteria using > > openjpa.metamodel=true). I am adding all tomee jars, but I would like to > > restrict to the barely necessary classes. I am using oracle JVM 7. > > > > I am not sure if this is also a bottleneck (it seems to be working > anyway) > > but I am keeping both the EntityManager, TimerService and JMS queue > > centralized in a @ApplicationScoped bean, so everytime a EJB needs one of > > them, they just retrieve from this "global" bean. > > > > So the idea here is to receive criticisms and suggestions. They will be > > very welcome. > > > > TIA > > > > Leo > > >
