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
>

Reply via email to