Yep or poll a db for tasks Le 23 nov. 2013 16:18, "Leonardo K. Shikida" <[email protected]> a écrit :
> well, I am not sure. These jobs can take almost an hour each and I´d like > to control in the consumer side. With JMS, I can even use an external > broker and consume these jobs in another machine, so I could keep CPU low > and the web front end responsive. The problem is that there aren't > stacktraces. It just hangs and I can't find where it's locked, no exception > is thrown. > > On the other side, I am really having a long time trying to tune activeMQ > for what I was supposing to be a simple queue task and if I can control the > number of simultaneous consumers using @async, they can just be low enough > so it won't impact the frontend responsiveness. > > So your suggestion is just to make the @timeout method to call another EJB > @Asynchronous method, right? > > > > [] > > Leo > > > On Sat, Nov 23, 2013 at 12:30 PM, Romain Manni-Bucau > <[email protected]>wrote: > > > I think your whole architecture can be simplified. In another terms i > > wouldnt spend time on tomee jms for that need. > > > > That said if you feel you have a bottleneck just take stack traces > > Le 23 nov. 2013 15:09, "Leonardo K. Shikida" <[email protected]> a > écrit : > > > > > sorry, I did't get it > > > > > > > > > > > > [] > > > > > > Leo > > > > > > > > > On Sat, Nov 23, 2013 at 12:05 PM, Romain Manni-Bucau > > > <[email protected]>wrote: > > > > > > > You said it, you dont handle correctly the lifecycle of your servers > > ;). > > > > Httpd allows graceful shutdown, that s easier > > > > Le 23 nov. 2013 14:41, "Leonardo K. Shikida" <[email protected]> a > > > écrit : > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
