Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.nicholson@gmail.com
 designates 209.85.210.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=N7GWXdSmU42/9pT5XA5ooxr3YhHP0fNxfsm0aWwAXZO6LTYvRLUFm1ZgTi2IhAHPFD
         GtSgJrGYQ41YinCEGxLL8UVQk5Mji2AF+ugfxpxDy7wuiQLbH2gIT8GrDtPGJ25zGu+Y
         WRVFXNLrTABQnPgCVLyPkk4/p4i3vNkH6BE7w=
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: what is best practices to implement Multithread + JMS ?
From: Robert Nicholson <robert.nicholson@gmail.com>
In-Reply-To: <7b3355cb0909181455v5664dd5ei61e0508e1f95a744@mail.gmail.com>
Date: Fri, 18 Sep 2009 21:42:02 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <8AE88184-E3AE-4DE0-BEAC-E2CEF2CF8DE3@gmail.com>
References: <4AB3DB56.6020409@gmail.com>
 <7b3355cb0909181455v5664dd5ei61e0508e1f95a744@mail.gmail.com>
To: users@activemq.apache.org

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 <czy11421@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)U8V4\@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