To me it seems really heavyweight. If you absolutely need a portable (read
nothing beyond JEE), clusterable and multi-threaded solution this is it. On
the other hand you may decide you don't REALLY have that needs. How would I
do it then?
1.- I would create a (stateless) (thread-safe) bean with one method that
selects a subset of servers from the (injected) complete list and pings them
2.- I would use DWR (reverse AJAX) to push the data to the browser
3.- I would fire the bean using a Quartz task with Spring's
MethodInvokingJobDetailFactoryBean and may be deploy the context using the
new JCA (rar) capabilities
Of course, if you haven't ever worked with Spring, Quartz and DWR that may
seem even more complicated..
Regards,
On Jan 15, 2008 5:57 PM, <glassfish_at_javadesktop.org> wrote:
> > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>