users@glassfish.java.net

Re: How could I implement and deploy a background process in Glassfish?

From: <glassfish_at_javadesktop.org>
Date: Tue, 15 Jan 2008 08:57:57 PST

> 3. The EJB Timer approach was one of my thoughts, but
> I have a lot of pings to do, and we are not supposed
> to do Threads in that beans, do we?

The portable and clusterable solution to this then is to use a combination of the EJB Timer and MDBs. I appreciate that this seems a bit heavyweight, but at the moment, that's all we have.

What you do is create an MDB that takes a parameter of somekind so that it will specifiy which subset of your 1400 sites to ping. You'll need to configure your MDB pool to handle as many instances as you have subsets (say your parameter selects a subset of 100 sites, then you'd need 1400 instances of the MDB). Note, this parameter can simply be a list of sites.

Then, you EJB Timer fires and creates 1 message for each subset (in this case, 14 subsets).

The cluster will ensure that the timer fires once, and you can cluster the MDBs to fire on different servers, if that's what you like.

It's a bit coarse, but using basic JEE components, this is how JEE "threads". But you get all the rest "for free", the clustering, the portability etc. And the simplicity. This is a really simple solution.

I've used this technique to great effect for parallelizing tasks. The task would fire (from an EJB Timer), I would create N messages, and submit them all via JMS. I would see improvements just running locally on a multicore laptops doing mundane tasks like creating 10000 customer statements. JMS offers little overhead to the problem. Certainly it will be faster to send 14 messages with 100 site each than 1400 messages with 1 site each. But in our case we DID send "10000" messages, and we were still DB bound, so the JMS impact wasn't as much as one would expect. Using 4 MDB instances, we got a 2.5x increase in our mundane processing on a 2 core laptop over a simple for loop doing each statement. Using a memory only JMS queue makes it even less overhead. We never clustered it, but with a cluster of machines you should scale even better (until the DB melts of course).

So, I'd give that a shot. Everything you need is in the JEE tutorial to pull this off (save tuning the number of instances, that's in the GF docs).
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=254018