You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Pravin Kundal <pr...@persistent.co.in> on 2007/05/21 14:55:23 UTC

Implementation of multithreading model on CMS ActiveMQ

I am bit confused from the JMS specification.

I want to implement mutithreaded model for producer/consumer.

Now I am confused at the point where,

I have only one destination object (Queue). 

So should I create mutiple threads, each thread having one session and one
producer.

OR, multiple threads running (concurrency controled) single session and
single producer.

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10718189
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Implementation of multithreading model on CMS ActiveMQ

Posted by Nathan Mittler <na...@gmail.com>.
That sounds more like it!  400 msgs/sec seemed awefully low to me.  Glad to
help!

On 5/22/07, Pravin Kundal <pr...@persistent.co.in> wrote:
>
>
> Hello Sir,
>
> Actually our producer was running on a very slower machine...so thats why
> we
> got very bad results.
>
> But your advices really helped us. Stomp is the fastest and for queue we
> are
> getting results upto 1500 msges/sec :)...more than sufficient for us.
>
> Thanking you for your help !!
>
>
>
> Mittler, Nathan wrote:
> >
> > Sorry ... The url should be "tcp://localhost:61613?wireFormat=stomp"
> >
> > See http://activemq.apache.org/cms/configuring.html
> >
> >> -----Original Message-----
> >> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in]
> >> Sent: Monday, May 21, 2007 12:34 PM
> >> To: users@activemq.apache.org
> >> Subject: RE: Implementation of multithreading model on CMS ActiveMQ
> >>
> >>
> >> I am trying to test it out using stomp.
> >> But it is giving me exceptions
> >> On Consumer Client: ActiveMQConnectionFactory - unknown
> >> Transport Factory.
> >>
> >> I tried with following brokerURI's
> >>
> >> std::string brokerURI =   "stomp://localhost:61613"
> >>                                      "?wireFormat=stomp"
> >>                         "&transport.useAsyncSend=true";
> >>
> >> std::string brokerURI =   "stomp://localhost:61613"
> >>
> >> std::string brokerURI =   "stomp://localhost:61616"
> >>
> >> can you please help us out?
> >>
> >> Thanks.
> >>
> >>
> >>
> >> Mittler, Nathan wrote:
> >> >
> >> >
> >> >>
> >> >> In the case I will need to implement the concurrency
> >> control over the
> >> >> session, so that only one thread can use the session, as
> >> sessions are
> >> >> implemented for serial use? Rght?
> >> >
> >> > Yes, you should add your own concurrency control for the session.
> >> >
> >> >>
> >> >> I tried the first case in which i implemented the multithreading,
> >> >> each thread running its own session and each session having one
> >> >> producer. But the results were not even close to our requriment
> >> >> (result in msges/sec).
> >> >>
> >> >
> >> > Were you using openwire or stomp as the protocol?  We have
> >> seen cases
> >> > where small messages with openwire cause extra delay due to
> >> the naggle
> >> > algorithm and that message footprints are smaller than their stomp
> >> > counterpart.  If you're using openwire, I suggest you
> >> switch over to
> >> > stomp and see if you have different results.  If that does
> >> the trick,
> >> > our next release will allow a user-specified TCP-NODELAY
> >> socket option
> >> > that should fix the problem for openwire (for small messages).
> >> >
> >> >> Do you think the other case can give us the better results
> >> (i.e. "The
> >> >> ActiveMQ-CPP implementation, however, will allow you to share a
> >> >> session across threads.")
> >> >>
> >> >
> >> > Without understanding your particular usage of the client, I would
> >> > guess that a different usage wouldn't help much.  Just to
> >> make sure,
> >> > however, you could slightly modify our example application
> >> >
> >> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/examp
> >> > le s/main.cpp and see if you can get it to meet your requirements.
> >> >
> >> >
> >> > Regards,
> >> > Nate
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Implementation-of-multithreading-model-o
> >> n-CMS-ActiveMQ-tf3790047s2354.html#a10722340
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10743030
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
Hello Sir,

Actually our producer was running on a very slower machine...so thats why we
got very bad results.

But your advices really helped us. Stomp is the fastest and for queue we are
getting results upto 1500 msges/sec :)...more than sufficient for us.

Thanking you for your help !!



Mittler, Nathan wrote:
> 
> Sorry ... The url should be "tcp://localhost:61613?wireFormat=stomp"
> 
> See http://activemq.apache.org/cms/configuring.html 
> 
>> -----Original Message-----
>> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
>> Sent: Monday, May 21, 2007 12:34 PM
>> To: users@activemq.apache.org
>> Subject: RE: Implementation of multithreading model on CMS ActiveMQ
>> 
>> 
>> I am trying to test it out using stomp.
>> But it is giving me exceptions
>> On Consumer Client: ActiveMQConnectionFactory - unknown 
>> Transport Factory.
>> 
>> I tried with following brokerURI's
>> 
>> std::string brokerURI =   "stomp://localhost:61613"
>>                                      "?wireFormat=stomp"
>> 		           "&transport.useAsyncSend=true";
>> 
>> std::string brokerURI =   "stomp://localhost:61613"
>> 
>> std::string brokerURI =   "stomp://localhost:61616"
>> 
>> can you please help us out?
>> 
>> Thanks.
>> 
>> 
>> 
>> Mittler, Nathan wrote:
>> > 
>> >  
>> >> 
>> >> In the case I will need to implement the concurrency 
>> control over the 
>> >> session, so that only one thread can use the session, as 
>> sessions are 
>> >> implemented for serial use? Rght?
>> > 
>> > Yes, you should add your own concurrency control for the session.
>> > 
>> >> 
>> >> I tried the first case in which i implemented the multithreading, 
>> >> each thread running its own session and each session having one 
>> >> producer. But the results were not even close to our requriment 
>> >> (result in msges/sec).
>> >> 
>> > 
>> > Were you using openwire or stomp as the protocol?  We have 
>> seen cases 
>> > where small messages with openwire cause extra delay due to 
>> the naggle 
>> > algorithm and that message footprints are smaller than their stomp 
>> > counterpart.  If you're using openwire, I suggest you 
>> switch over to 
>> > stomp and see if you have different results.  If that does 
>> the trick, 
>> > our next release will allow a user-specified TCP-NODELAY 
>> socket option 
>> > that should fix the problem for openwire (for small messages).
>> > 
>> >> Do you think the other case can give us the better results 
>> (i.e. "The 
>> >> ActiveMQ-CPP implementation, however, will allow you to share a 
>> >> session across threads.")
>> >> 
>> > 
>> > Without understanding your particular usage of the client, I would 
>> > guess that a different usage wouldn't help much.  Just to 
>> make sure, 
>> > however, you could slightly modify our example application 
>> > 
>> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/examp
>> > le s/main.cpp and see if you can get it to meet your requirements.
>> > 
>> > 
>> > Regards,
>> > Nate
>> > 
>> > 
>> 
>> --
>> View this message in context: 
>> http://www.nabble.com/Implementation-of-multithreading-model-o
>> n-CMS-ActiveMQ-tf3790047s2354.html#a10722340
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10743030
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Timothy Bish <ti...@sensis.com>.
You could try pulling the latest code from trunk to see what effect the
TCP_NODELAY option will have on performance on your machine.  The code
in trunk sets TCP_NODELAY on by default.

regards
Tim

On Mon, 2007-05-21 at 10:52 -0700, Pravin Kundal wrote:
> Hey Sir, the string you sent "WORKED"..........thanks!!
> 
> Stomp improved the results but still away from our target. posting some
> results. Message was string of around size 50 to 70 characters. All with
> Non_Persistent message relibility (i.e. atmost once)
> 
> Here are our readings:
> A]
> Using Openwire, Asynchronous Consumer. 
>   1] Multi Threading : one session, one producer per Thread:     214
> msges/sec.
>   2] Multi Threading : one session, mutiple producers. concurrency
> implemented in client:     122 
>       msges/sec.
> 
> B] 
> 1) Using Stomp, Asynchronous Consumer. 
> 
>   1] Single Thread:      410 msges/sec.
>   2] Multi Threading (2 Threads): one session, one producer per Thread:    
> 357 msges/sec.
>   3] Multi Threading (5 Threads): one session, one producer per Thread:    
> 413 msges/sec.
>   4] Multi Threading (5 Threads): one session, one producer per Thread:    
> 387 msges/sec.
> 
> 2) Using Stomp, Synchronous Consumer. 
>  
>   1] Single Thread:      367 msges/sec.
> 
> So from the above results maximum is 413 what we got. Our target is upto 600
> to 650 msges/sec.
> 
> Also both producer and consumer are CMS ActiveMQ.
> 
> Our Java team tested using Java clients (producer and consumer) with
> ActiveMQ broker with 10 threads running they are getting around 700
> msges/sec. Is it because java supports internal multithreading or something
> else. Or any other reason????
> 
> I really appreciate for you quick and working out responses :) Thanks.
> 
> 
> 
> 
> Mittler, Nathan wrote:
> > 
> > Sorry ... The url should be "tcp://localhost:61613?wireFormat=stomp"
> > 
> > See http://activemq.apache.org/cms/configuring.html 
> > 
> >> -----Original Message-----
> >> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
> >> Sent: Monday, May 21, 2007 12:34 PM
> >> To: users@activemq.apache.org
> >> Subject: RE: Implementation of multithreading model on CMS ActiveMQ
> >> 
> >> 
> >> I am trying to test it out using stomp.
> >> But it is giving me exceptions
> >> On Consumer Client: ActiveMQConnectionFactory - unknown 
> >> Transport Factory.
> >> 
> >> I tried with following brokerURI's
> >> 
> >> std::string brokerURI =   "stomp://localhost:61613"
> >>                                      "?wireFormat=stomp"
> >> 		           "&transport.useAsyncSend=true";
> >> 
> >> std::string brokerURI =   "stomp://localhost:61613"
> >> 
> >> std::string brokerURI =   "stomp://localhost:61616"
> >> 
> >> can you please help us out?
> >> 
> >> Thanks.
> >> 
> >> 
> >> 
> >> Mittler, Nathan wrote:
> >> > 
> >> >  
> >> >> 
> >> >> In the case I will need to implement the concurrency 
> >> control over the 
> >> >> session, so that only one thread can use the session, as 
> >> sessions are 
> >> >> implemented for serial use? Rght?
> >> > 
> >> > Yes, you should add your own concurrency control for the session.
> >> > 
> >> >> 
> >> >> I tried the first case in which i implemented the multithreading, 
> >> >> each thread running its own session and each session having one 
> >> >> producer. But the results were not even close to our requriment 
> >> >> (result in msges/sec).
> >> >> 
> >> > 
> >> > Were you using openwire or stomp as the protocol?  We have 
> >> seen cases 
> >> > where small messages with openwire cause extra delay due to 
> >> the naggle 
> >> > algorithm and that message footprints are smaller than their stomp 
> >> > counterpart.  If you're using openwire, I suggest you 
> >> switch over to 
> >> > stomp and see if you have different results.  If that does 
> >> the trick, 
> >> > our next release will allow a user-specified TCP-NODELAY 
> >> socket option 
> >> > that should fix the problem for openwire (for small messages).
> >> > 
> >> >> Do you think the other case can give us the better results 
> >> (i.e. "The 
> >> >> ActiveMQ-CPP implementation, however, will allow you to share a 
> >> >> session across threads.")
> >> >> 
> >> > 
> >> > Without understanding your particular usage of the client, I would 
> >> > guess that a different usage wouldn't help much.  Just to 
> >> make sure, 
> >> > however, you could slightly modify our example application 
> >> > 
> >> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/examp
> >> > le s/main.cpp and see if you can get it to meet your requirements.
> >> > 
> >> > 
> >> > Regards,
> >> > Nate
> >> > 
> >> > 
> >> 
> >> --
> >> View this message in context: 
> >> http://www.nabble.com/Implementation-of-multithreading-model-o
> >> n-CMS-ActiveMQ-tf3790047s2354.html#a10722340
> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >> 
> >> 
> > 
> > 
> 

RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
Hey Sir, the string you sent "WORKED"..........thanks!!

Stomp improved the results but still away from our target. posting some
results. Message was string of around size 50 to 70 characters. All with
Non_Persistent message relibility (i.e. atmost once)

Here are our readings:
A]
Using Openwire, Asynchronous Consumer. 
  1] Multi Threading : one session, one producer per Thread:     214
msges/sec.
  2] Multi Threading : one session, mutiple producers. concurrency
implemented in client:     122 
      msges/sec.

B] 
1) Using Stomp, Asynchronous Consumer. 

  1] Single Thread:      410 msges/sec.
  2] Multi Threading (2 Threads): one session, one producer per Thread:    
357 msges/sec.
  3] Multi Threading (5 Threads): one session, one producer per Thread:    
413 msges/sec.
  4] Multi Threading (5 Threads): one session, one producer per Thread:    
387 msges/sec.

2) Using Stomp, Synchronous Consumer. 
 
  1] Single Thread:      367 msges/sec.

So from the above results maximum is 413 what we got. Our target is upto 600
to 650 msges/sec.

Also both producer and consumer are CMS ActiveMQ.

Our Java team tested using Java clients (producer and consumer) with
ActiveMQ broker with 10 threads running they are getting around 700
msges/sec. Is it because java supports internal multithreading or something
else. Or any other reason????

I really appreciate for you quick and working out responses :) Thanks.




Mittler, Nathan wrote:
> 
> Sorry ... The url should be "tcp://localhost:61613?wireFormat=stomp"
> 
> See http://activemq.apache.org/cms/configuring.html 
> 
>> -----Original Message-----
>> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
>> Sent: Monday, May 21, 2007 12:34 PM
>> To: users@activemq.apache.org
>> Subject: RE: Implementation of multithreading model on CMS ActiveMQ
>> 
>> 
>> I am trying to test it out using stomp.
>> But it is giving me exceptions
>> On Consumer Client: ActiveMQConnectionFactory - unknown 
>> Transport Factory.
>> 
>> I tried with following brokerURI's
>> 
>> std::string brokerURI =   "stomp://localhost:61613"
>>                                      "?wireFormat=stomp"
>> 		           "&transport.useAsyncSend=true";
>> 
>> std::string brokerURI =   "stomp://localhost:61613"
>> 
>> std::string brokerURI =   "stomp://localhost:61616"
>> 
>> can you please help us out?
>> 
>> Thanks.
>> 
>> 
>> 
>> Mittler, Nathan wrote:
>> > 
>> >  
>> >> 
>> >> In the case I will need to implement the concurrency 
>> control over the 
>> >> session, so that only one thread can use the session, as 
>> sessions are 
>> >> implemented for serial use? Rght?
>> > 
>> > Yes, you should add your own concurrency control for the session.
>> > 
>> >> 
>> >> I tried the first case in which i implemented the multithreading, 
>> >> each thread running its own session and each session having one 
>> >> producer. But the results were not even close to our requriment 
>> >> (result in msges/sec).
>> >> 
>> > 
>> > Were you using openwire or stomp as the protocol?  We have 
>> seen cases 
>> > where small messages with openwire cause extra delay due to 
>> the naggle 
>> > algorithm and that message footprints are smaller than their stomp 
>> > counterpart.  If you're using openwire, I suggest you 
>> switch over to 
>> > stomp and see if you have different results.  If that does 
>> the trick, 
>> > our next release will allow a user-specified TCP-NODELAY 
>> socket option 
>> > that should fix the problem for openwire (for small messages).
>> > 
>> >> Do you think the other case can give us the better results 
>> (i.e. "The 
>> >> ActiveMQ-CPP implementation, however, will allow you to share a 
>> >> session across threads.")
>> >> 
>> > 
>> > Without understanding your particular usage of the client, I would 
>> > guess that a different usage wouldn't help much.  Just to 
>> make sure, 
>> > however, you could slightly modify our example application 
>> > 
>> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/examp
>> > le s/main.cpp and see if you can get it to meet your requirements.
>> > 
>> > 
>> > Regards,
>> > Nate
>> > 
>> > 
>> 
>> --
>> View this message in context: 
>> http://www.nabble.com/Implementation-of-multithreading-model-o
>> n-CMS-ActiveMQ-tf3790047s2354.html#a10722340
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10723703
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by "Mittler, Nathan" <na...@sensis.com>.
Sorry ... The url should be "tcp://localhost:61613?wireFormat=stomp"

See http://activemq.apache.org/cms/configuring.html 

> -----Original Message-----
> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
> Sent: Monday, May 21, 2007 12:34 PM
> To: users@activemq.apache.org
> Subject: RE: Implementation of multithreading model on CMS ActiveMQ
> 
> 
> I am trying to test it out using stomp.
> But it is giving me exceptions
> On Consumer Client: ActiveMQConnectionFactory - unknown 
> Transport Factory.
> 
> I tried with following brokerURI's
> 
> std::string brokerURI =   "stomp://localhost:61613"
>                                      "?wireFormat=stomp"
> 		           "&transport.useAsyncSend=true";
> 
> std::string brokerURI =   "stomp://localhost:61613"
> 
> std::string brokerURI =   "stomp://localhost:61616"
> 
> can you please help us out?
> 
> Thanks.
> 
> 
> 
> Mittler, Nathan wrote:
> > 
> >  
> >> 
> >> In the case I will need to implement the concurrency 
> control over the 
> >> session, so that only one thread can use the session, as 
> sessions are 
> >> implemented for serial use? Rght?
> > 
> > Yes, you should add your own concurrency control for the session.
> > 
> >> 
> >> I tried the first case in which i implemented the multithreading, 
> >> each thread running its own session and each session having one 
> >> producer. But the results were not even close to our requriment 
> >> (result in msges/sec).
> >> 
> > 
> > Were you using openwire or stomp as the protocol?  We have 
> seen cases 
> > where small messages with openwire cause extra delay due to 
> the naggle 
> > algorithm and that message footprints are smaller than their stomp 
> > counterpart.  If you're using openwire, I suggest you 
> switch over to 
> > stomp and see if you have different results.  If that does 
> the trick, 
> > our next release will allow a user-specified TCP-NODELAY 
> socket option 
> > that should fix the problem for openwire (for small messages).
> > 
> >> Do you think the other case can give us the better results 
> (i.e. "The 
> >> ActiveMQ-CPP implementation, however, will allow you to share a 
> >> session across threads.")
> >> 
> > 
> > Without understanding your particular usage of the client, I would 
> > guess that a different usage wouldn't help much.  Just to 
> make sure, 
> > however, you could slightly modify our example application 
> > 
> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/examp
> > le s/main.cpp and see if you can get it to meet your requirements.
> > 
> > 
> > Regards,
> > Nate
> > 
> > 
> 
> --
> View this message in context: 
> http://www.nabble.com/Implementation-of-multithreading-model-o
> n-CMS-ActiveMQ-tf3790047s2354.html#a10722340
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> 
> 

RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
I am trying to test it out using stomp.
But it is giving me exceptions 
On Consumer Client: ActiveMQConnectionFactory - unknown Transport Factory.

I tried with following brokerURI's

std::string brokerURI =   "stomp://localhost:61613"
                                     "?wireFormat=stomp"
		           "&transport.useAsyncSend=true";

std::string brokerURI =   "stomp://localhost:61613"

std::string brokerURI =   "stomp://localhost:61616"

can you please help us out?

Thanks.



Mittler, Nathan wrote:
> 
>  
>> 
>> In the case I will need to implement the concurrency control 
>> over the session, so that only one thread can use the 
>> session, as sessions are implemented for serial use? Rght?
> 
> Yes, you should add your own concurrency control for the session.
> 
>> 
>> I tried the first case in which i implemented the 
>> multithreading, each thread running its own session and each 
>> session having one producer. But the results were not even 
>> close to our requriment (result in msges/sec).
>> 
> 
> Were you using openwire or stomp as the protocol?  We have seen cases
> where small messages with openwire cause extra delay due to the naggle
> algorithm and that message footprints are smaller than their stomp
> counterpart.  If you're using openwire, I suggest you switch over to
> stomp and see if you have different results.  If that does the trick,
> our next release will allow a user-specified TCP-NODELAY socket option
> that should fix the problem for openwire (for small messages).
> 
>> Do you think the other case can give us the better results 
>> (i.e. "The ActiveMQ-CPP implementation, however, will allow 
>> you to share a session across threads.")
>> 
> 
> Without understanding your particular usage of the client, I would guess
> that a different usage wouldn't help much.  Just to make sure, however,
> you could slightly modify our example application
> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/example
> s/main.cpp and see if you can get it to meet your requirements.
> 
> 
> Regards,
> Nate
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10722340
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
Sorry,
I missed the second line of link. I could access it. Thanks

Pravin Kundal wrote:
> 
> I couldn't access the link below. 
> 
> Is it the same example that Apache-ActiveMQ ship with the CMS library?
> 
> Thanks a lot.
> 
> 
> Mittler, Nathan wrote:
>> 
>>  
>>> 
>>> In the case I will need to implement the concurrency control 
>>> over the session, so that only one thread can use the 
>>> session, as sessions are implemented for serial use? Rght?
>> 
>> Yes, you should add your own concurrency control for the session.
>> 
>>> 
>>> I tried the first case in which i implemented the 
>>> multithreading, each thread running its own session and each 
>>> session having one producer. But the results were not even 
>>> close to our requriment (result in msges/sec).
>>> 
>> 
>> Were you using openwire or stomp as the protocol?  We have seen cases
>> where small messages with openwire cause extra delay due to the naggle
>> algorithm and that message footprints are smaller than their stomp
>> counterpart.  If you're using openwire, I suggest you switch over to
>> stomp and see if you have different results.  If that does the trick,
>> our next release will allow a user-specified TCP-NODELAY socket option
>> that should fix the problem for openwire (for small messages).
>> 
>>> Do you think the other case can give us the better results 
>>> (i.e. "The ActiveMQ-CPP implementation, however, will allow 
>>> you to share a session across threads.")
>>> 
>> 
>> Without understanding your particular usage of the client, I would guess
>> that a different usage wouldn't help much.  Just to make sure, however,
>> you could slightly modify our example application
>> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/example
>> s/main.cpp and see if you can get it to meet your requirements.
>> 
>> 
>> Regards,
>> Nate
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10721114
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
I couldn't access the link below. 

Is it the same example that Apache-ActiveMQ ship with the CMS library?

Thanks a lot.


Mittler, Nathan wrote:
> 
>  
>> 
>> In the case I will need to implement the concurrency control 
>> over the session, so that only one thread can use the 
>> session, as sessions are implemented for serial use? Rght?
> 
> Yes, you should add your own concurrency control for the session.
> 
>> 
>> I tried the first case in which i implemented the 
>> multithreading, each thread running its own session and each 
>> session having one producer. But the results were not even 
>> close to our requriment (result in msges/sec).
>> 
> 
> Were you using openwire or stomp as the protocol?  We have seen cases
> where small messages with openwire cause extra delay due to the naggle
> algorithm and that message footprints are smaller than their stomp
> counterpart.  If you're using openwire, I suggest you switch over to
> stomp and see if you have different results.  If that does the trick,
> our next release will allow a user-specified TCP-NODELAY socket option
> that should fix the problem for openwire (for small messages).
> 
>> Do you think the other case can give us the better results 
>> (i.e. "The ActiveMQ-CPP implementation, however, will allow 
>> you to share a session across threads.")
>> 
> 
> Without understanding your particular usage of the client, I would guess
> that a different usage wouldn't help much.  Just to make sure, however,
> you could slightly modify our example application
> https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/example
> s/main.cpp and see if you can get it to meet your requirements.
> 
> 
> Regards,
> Nate
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10721096
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by "Mittler, Nathan" <na...@sensis.com>.
 
> 
> In the case I will need to implement the concurrency control 
> over the session, so that only one thread can use the 
> session, as sessions are implemented for serial use? Rght?

Yes, you should add your own concurrency control for the session.

> 
> I tried the first case in which i implemented the 
> multithreading, each thread running its own session and each 
> session having one producer. But the results were not even 
> close to our requriment (result in msges/sec).
> 

Were you using openwire or stomp as the protocol?  We have seen cases
where small messages with openwire cause extra delay due to the naggle
algorithm and that message footprints are smaller than their stomp
counterpart.  If you're using openwire, I suggest you switch over to
stomp and see if you have different results.  If that does the trick,
our next release will allow a user-specified TCP-NODELAY socket option
that should fix the problem for openwire (for small messages).

> Do you think the other case can give us the better results 
> (i.e. "The ActiveMQ-CPP implementation, however, will allow 
> you to share a session across threads.")
> 

Without understanding your particular usage of the client, I would guess
that a different usage wouldn't help much.  Just to make sure, however,
you could slightly modify our example application
https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/example
s/main.cpp and see if you can get it to meet your requirements.


Regards,
Nate

RE: Implementation of multithreading model on CMS ActiveMQ

Posted by Pravin Kundal <pr...@persistent.co.in>.
Thank you Sir for you immediate reply !

Ok now in the case where....

"The ActiveMQ-CPP implementation, however, will allow you to share a session
across threads."

In the case I will need to implement the concurrency control over the
session, so that only one thread can use the session, as sessions are
implemented for serial use? Rght?

I tried the first case in which i implemented the multithreading, each
thread running its own session and each session having one producer. But the
results were not even close to our requriment (result in msges/sec).

Do you think the other case can give us the better results (i.e. "The
ActiveMQ-CPP implementation, however, will allow you to share a session
across threads.")

thanks once again.


Mittler, Nathan wrote:
> 
> The formal JMS/CMS definition of a Session implies that each thread
> would get its own session.  The ActiveMQ-CPP implementation, however,
> will allow you to share a session across threads.  
> 
> For consumers, it should be known that each session has a single message
> dispatch thread, so a slow asynchronous consumer (one that processes
> messages in the session's thread context) would slow down other
> consumers of the same session. 
> 
> If you plan on using synchronous consumers (via the receive method), you
> should not have multiple threads calling receive() on the same consumer.
> 
> 
> Nate
> 
>> -----Original Message-----
>> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
>> Sent: Monday, May 21, 2007 8:55 AM
>> To: users@activemq.apache.org
>> Subject: Implementation of multithreading model on CMS ActiveMQ
>> 
>> 
>> I am bit confused from the JMS specification.
>> 
>> I want to implement mutithreaded model for producer/consumer.
>> 
>> Now I am confused at the point where,
>> 
>> I have only one destination object (Queue). 
>> 
>> So should I create mutiple threads, each thread having one 
>> session and one producer.
>> 
>> OR, multiple threads running (concurrency controled) single 
>> session and single producer.
>> 
>> --
>> View this message in context: 
>> http://www.nabble.com/Implementation-of-multithreading-model-o
>> n-CMS-ActiveMQ-tf3790047s2354.html#a10718189
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Implementation-of-multithreading-model-on-CMS-ActiveMQ-tf3790047s2354.html#a10720173
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


RE: Implementation of multithreading model on CMS ActiveMQ

Posted by "Mittler, Nathan" <na...@sensis.com>.
The formal JMS/CMS definition of a Session implies that each thread
would get its own session.  The ActiveMQ-CPP implementation, however,
will allow you to share a session across threads.  

For consumers, it should be known that each session has a single message
dispatch thread, so a slow asynchronous consumer (one that processes
messages in the session's thread context) would slow down other
consumers of the same session. 

If you plan on using synchronous consumers (via the receive method), you
should not have multiple threads calling receive() on the same consumer.


Nate

> -----Original Message-----
> From: Pravin Kundal [mailto:pravin_kundal@persistent.co.in] 
> Sent: Monday, May 21, 2007 8:55 AM
> To: users@activemq.apache.org
> Subject: Implementation of multithreading model on CMS ActiveMQ
> 
> 
> I am bit confused from the JMS specification.
> 
> I want to implement mutithreaded model for producer/consumer.
> 
> Now I am confused at the point where,
> 
> I have only one destination object (Queue). 
> 
> So should I create mutiple threads, each thread having one 
> session and one producer.
> 
> OR, multiple threads running (concurrency controled) single 
> session and single producer.
> 
> --
> View this message in context: 
> http://www.nabble.com/Implementation-of-multithreading-model-o
> n-CMS-ActiveMQ-tf3790047s2354.html#a10718189
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> 
>