I've been looking at DMLC lately.
Acknowledge semantics are a little different when using it though?
Isn't there the notion that you acknowledge before dispatch and
therefore there
lies an opportunity to acknowledge something from the queue and not
actually process it
because of an outage.
JMS doesn't let you commit the session in any other thread than the
thread of control
of the session so you aren't going to have a guarantee that you
actually processed
what was acknowledged/committed in the Session.
Also, DMLC doesn't do anything for you regarding order of processing
so how does
Spring address that problem? Am I expected to have N's DMLC's and
dispatch based
on my own rules rather than something that can share from a common
thread pool but
still guarantee some order of processing?
On Sep 18, 2009, at 4:55 PM, Bruce Snyder wrote:
On Fri, Sep 18, 2009 at 1:11 PM, czy11421 <czy11...@gmail.com> wrote:
what is best practices to implement Multithread + JMS ?
Let us assume we are listening financial market data feed. I have
this
coding like this:
class MyClass implements Listener{
private final ExecutorService pool =
Executors.newFixedThreadPool(poolSize);
onMessage(...){
pool.execute(new Handler(Message)); }
class Handler implements Runnable {
public run(){
// get data, same it into db
}
}
}
Anybody can share your experiences in this topic ?
When building JMS consumers, I recommend the use of the Spring
DefaultMessageListenerContainer:
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/listener/DefaultMessageListenerContainer.html
The DMLC provides the ability to set a TaskExecutor, a range of
concurrent consumers, various tiered caching levels (connection,
session, consumer), it works with transactions and much more. The
reason I recommend the DMLC (or one of the other message listener
containers) is because writing JMS clients is a lot of work and the
Spring message listener containers dramatically reduce the complexity
thereby saving you quite a lot of time. Given the tremendous
flexibility, the robustness, the high amount of configurability and
the widespread deployment in businesses all over the world (including
in the financial markets), there really no reason not to use it.
Together with the Spring CachingConnectionFactory
(http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/connection/CachingConnectionFactory.html
),
these tools will speed your JMS development client developer markedly.
Bruce
--
perl -e 'print unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!
G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
