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