You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Paul French <pa...@frenchiesystems.com> on 2007/01/15 20:03:24 UTC

Session.DUPS_OK_ACKNOWLEDGE

ActivemQ 4.1.0


Where do I set Session.DUPS_OK_ACKNOWLEDGE this? I'm trying to increase
performance of the messaging layer and I'm going through the performance
guide at 
http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html
http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html 

I can send out a 1000 messages a second no problem but the rest of the
messaging layer is very slow so I need some help here.

My scenario is client creates many messages and sends async to the broker
(one connection, one session). The client also creates a temporary queue to
receive replies on. The client also starts a number of consumers to listen
on the temp queue.

A consumer consumes the messages and then replies by placing a message on
the temporary queue.

My client receives the reply via the temp queue.


I have no need for Quality Of Service or persistence. So far for the cleint
I have set the following properties to improve performance:

  <bean id="connectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
    <property name="targetConnectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL">
         
<value>tcp://192.168.160.86:61616?jms.prefetchPolicy.queuePrefetch=100</value>
        </property>
        <property name="useAsyncSend"><value>TRUE</value></property>
        <property name="optimizeAcknowledge"><value>TRUE</value></property>
      </bean>
    </property>
  </bean>

Is optimizeAcknowledge related to Session.DUPS_OK_ACKNOWLEDGE?

For the server side I have used the same properties for now:

  <bean id="connectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
    <property name="targetConnectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL">
         
<value>tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=100</value>
        </property>
        <property name="useAsyncSend"><value>TRUE</value></property>
        <property name="optimizeAcknowledge"><value>TRUE</value></property>
      </bean>
    </property>
  </bean>


The server and broker run on the same machine for this test but will not in
production hence I have not bothered trying to embed the broker in the
server.

Baiscally for this test my client is punching out about 1000 messages and I
want to see how long it takes to get replies. At the moment I am pumping out
about 1000 messages in about 2 seconds but it takes 20 seconds to get the
1000 replies. I am obviously missing something here?? Any pointers would be
great.

I am using a laptop as my client and a big chunky solaris box as my server
all on the same local LAN.
-- 
View this message in context: http://www.nabble.com/Session.DUPS_OK_ACKNOWLEDGE-tf3016262.html#a8376423
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>
> Okay thanks.
>
> Just for my understanding, why is it still super quick to send messages
> using JmsTemplate (using Async and a SingleConnectionFactory) yet incredibly
> slow to consume them (using SingleConnectionFactory)?

Because sending messages doesn't do very much. Creating and destroying
consumers is a lot of work for the broker - as soon as a consumer is
created ActiveMQ will start streaming messages to the consumer as it
expects a well behaving JMS client to want to stream messages as fast
as possible...

http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html



> What is your recommended approach for consumming messages when using a
> JmsTemplate in a standalone environment?

Not to use JmsTemplate at all for consuming. If you don't wanna use
Jencks, MDBs or Spring's message containers, then just use the JMS API
and create a bunch of sessions and MessageConsumers.

-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by Paul French <pa...@frenchiesystems.com>.
Okay thanks.

Just for my understanding, why is it still super quick to send messages
using JmsTemplate (using Async and a SingleConnectionFactory) yet incredibly
slow to consume them (using SingleConnectionFactory)?

What is your recommended approach for consumming messages when using a
JmsTemplate in a standalone environment?


James.Strachan wrote:
> 
> On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>>
>> I have read all this before a while back and thought I had covered
>> myself........
>>
>> Let me re-iterate (please correct me if I am wrong)
> 
> 
>> On the server side for consuming messages I use the JmsTemplate. I resuse
>> the same connection. I suppose my question is the same as above, What is
>> the
>> cost of creating a session and consumer on the fly here?
> 
> If you care about performance, never use JmsTemplate for consuming
> messages. Each time an attempt is made to receive a message a new
> connection, session, consumer is created. The broker will then start a
> new subscription up, start dispatching messages to it. On receiving
> one message, the JmsTemplate will then close down the consumer,
> session, connection.
> 
> Basically the slowest possible way of consuming messages in JMS is via
> JmsTemplate - and the worst place to use this is the server when you
> care about performance
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/Session.DUPS_OK_ACKNOWLEDGE-tf3016262.html#a8390487
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>
> I have read all this before a while back and thought I had covered
> myself........
>
> Let me re-iterate (please correct me if I am wrong)


> On the server side for consuming messages I use the JmsTemplate. I resuse
> the same connection. I suppose my question is the same as above, What is the
> cost of creating a session and consumer on the fly here?

If you care about performance, never use JmsTemplate for consuming
messages. Each time an attempt is made to receive a message a new
connection, session, consumer is created. The broker will then start a
new subscription up, start dispatching messages to it. On receiving
one message, the JmsTemplate will then close down the consumer,
session, connection.

Basically the slowest possible way of consuming messages in JMS is via
JmsTemplate - and the worst place to use this is the server when you
care about performance

-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by Paul French <pa...@frenchiesystems.com>.
I have read all this before a while back and thought I had covered
myself........

Let me re-iterate (please correct me if I am wrong)

On the client side for sending messages I use the JmsTemplate, I am okay
since I resuse the same connection and since the messaging is async the cost
of creating a session and producer for each call is minimal.

On the client side for consuming messages I am using the Spring
SimpleMessageListenerContainer (where the same connection is re-used). I
assume under the hood Spring uses the JmsTemplate. What is the cost of
creating a session and consumer on the fly here, I'm not so sure? I suppose
I need to know what is the equivalent of async sending but when consuming
messages?

On the server side for sending messages I use the JmsTemplate, I am okay
since I resuse the same connection and since the messaging is async the cost
of creating a session and producer for each call is minimal.

On the server side for consuming messages I use the JmsTemplate. I resuse
the same connection. I suppose my question is the same as above, What is the
cost of creating a session and consumer on the fly here?

I'll wait on your answers before spectualting on what to do next e.g. Jencks




James.Strachan wrote:
> 
> On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>>
>> Why? I obviously don't know something?
> 
> http://incubator.apache.org/activemq/jmstemplate-gotchas.html
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/Session.DUPS_OK_ACKNOWLEDGE-tf3016262.html#a8388808
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>
> Why? I obviously don't know something?

http://incubator.apache.org/activemq/jmstemplate-gotchas.html
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by Paul French <pa...@frenchiesystems.com>.
Why? I obviously don't know something? 



James.Strachan wrote:
> 
> On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
> Ah...
> 
> Never ever use JmsTemplate for consuming messages. That should fix it.
> -- 
> 
> 

-- 
View this message in context: http://www.nabble.com/Session.DUPS_OK_ACKNOWLEDGE-tf3016262.html#a8387965
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/16/07, James Strachan <ja...@gmail.com> wrote:
> On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
> >
> > I'll implement your current comments and see what happens. I'm still not sure
> > where to set Session.DUPS_OK_ACKNOWLEDGE since I am using the Spring
> > JmsTemplate and the template creates the sessions for you on the fly.
>
> You have to noodle the spring javadoc a bit to find it...
>
> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/jms/support/JmsAccessor.html#setSessionAcknowledgeModeName(java.lang.String)
>
> >  I will
> > have a dig about in the javadoc. Any other ideas how to make the whole
> > process faster?
> >
> > On the client side I am using a pool of consumers (via the Spring
> > SimpleMessageListenerContainer)
>
> But the server side is where you want the pool of consumers. (There's
> no real point having a pool on the consumer side unless you are doing
> something heavy duty and single threaded after receiving the reply)
>
>
> > Just FYI on the server side a number of threads are started where each
> > thread reads from the main queue and then simply puts  a response on the
> > temp queue. I don't use a SimpleMessageListenerContainer on the server side
> > just a number of pre-configured threads (8 threads) that use the same spring
> > single connection factory and JmsTemplates.........
>
> Ah...
>
> Never ever use JmsTemplate for consuming messages. That should fix it.

http://incubator.apache.org/activemq/jmstemplate-gotchas.html
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/16/07, Paul French <pa...@frenchiesystems.com> wrote:
>
> I'll implement your current comments and see what happens. I'm still not sure
> where to set Session.DUPS_OK_ACKNOWLEDGE since I am using the Spring
> JmsTemplate and the template creates the sessions for you on the fly.

You have to noodle the spring javadoc a bit to find it...

http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/jms/support/JmsAccessor.html#setSessionAcknowledgeModeName(java.lang.String)

>  I will
> have a dig about in the javadoc. Any other ideas how to make the whole
> process faster?
>
> On the client side I am using a pool of consumers (via the Spring
> SimpleMessageListenerContainer)

But the server side is where you want the pool of consumers. (There's
no real point having a pool on the consumer side unless you are doing
something heavy duty and single threaded after receiving the reply)


> Just FYI on the server side a number of threads are started where each
> thread reads from the main queue and then simply puts  a response on the
> temp queue. I don't use a SimpleMessageListenerContainer on the server side
> just a number of pre-configured threads (8 threads) that use the same spring
> single connection factory and JmsTemplates.........

Ah...

Never ever use JmsTemplate for consuming messages. That should fix it.
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by Paul French <pa...@frenchiesystems.com>.
I'll implement your current comments and see what happens. I'm still not sure
where to set Session.DUPS_OK_ACKNOWLEDGE since I am using the Spring
JmsTemplate and the template creates the sessions for you on the fly. I will
have a dig about in the javadoc. Any other ideas how to make the whole
process faster?

On the client side I am using a pool of consumers (via the Spring
SimpleMessageListenerContainer)

  <bean id="listenerContainer"
class="org.springframework.jms.listener.SimpleMessageListenerContainer">
    <property name="concurrentConsumers" value="4"/>
    <property name="connectionFactory" ref="connectionFactory" />
    <property name="destination" ref="temporaryQueue" />
    <property name="messageListener" ref="client" />
  </bean>


My connection factory on the client side is

  <bean id="connectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
    <property name="targetConnectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL">
         
<value>tcp://192.168.160.86:61616?jms.prefetchPolicy.queuePrefetch=100</value>
        </property>
        <property name="useAsyncSend"><value>TRUE</value></property>
        <property name="optimizeAcknowledge"><value>TRUE</value></property>
      </bean>
    </property>
  </bean>

What I am doing is........

client produces message -> Broker (main queue) -> server consumes message
from main queue

server sends reply (produces message) -> broker(temp queue) -> client
consumes message from temp queue


Just FYI on the server side a number of threads are started where each
thread reads from the main queue and then simply puts  a response on the
temp queue. I don't use a SimpleMessageListenerContainer on the server side
just a number of pre-configured threads (8 threads) that use the same spring
single connection factory and JmsTemplates.........

  <bean id="connectionFactory"
class="org.springframework.jms.connection.SingleConnectionFactory">
    <property name="targetConnectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL">
         
<value>tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=100</value>
        </property>
        <property name="useAsyncSend"><value>TRUE</value></property>
        <property name="optimizeAcknowledge"><value>TRUE</value></property>
      </bean>
    </property>
  </bean>

  <bean id="requestServer" singleton="false"
class="com.frenchiesystems.ttre.server.implemented.RequestServer">
    <property name="noOfThreads"><value>8</value></property>
    <property name="replyJmsTemplate"><ref
local="replyJmsTemplate"/></property>
    <property name="receiveJmsTemplate"><ref
local="receiveJmsTemplate"/></property>
  </bean>

  <bean id="receiveJmsTemplate"
class="org.springframework.jms.core.JmsTemplate">
    <property name="connectionFactory"><ref
local="connectionFactory"/></property>
    <property name="defaultDestination">
      <bean class="org.apache.activemq.command.ActiveMQQueue">
        <constructor-arg
index="0"><value>MAIN_QUEUE</value></constructor-arg> 
      </bean>
    </property>
  </bean>

  <bean id="replyJmsTemplate"
class="org.springframework.jms.core.JmsTemplate">
    <property name="connectionFactory"><ref
local="connectionFactory"/></property>
  </bean>



James.Strachan wrote:
> 
> On 1/15/07, Paul French <pa...@frenchiesystems.com> wrote:
>>
>> ActivemQ 4.1.0
>>
>>
>> Where do I set Session.DUPS_OK_ACKNOWLEDGE this?
> 
> http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Connection.html#createSession(boolean,%20int)
> 
> 
>> I'm trying to increase
>> performance of the messaging layer and I'm going through the performance
>> guide at
>> http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html
>> http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html
>>
>> I can send out a 1000 messages a second no problem but the rest of the
>> messaging layer is very slow so I need some help here.
>>
>> My scenario is client creates many messages and sends async to the broker
>> (one connection, one session). The client also creates a temporary queue
>> to
>> receive replies on. The client also starts a number of consumers to
>> listen
>> on the temp queue.
>>
>> A consumer consumes the messages and then replies by placing a message on
>> the temporary queue.
>>
>> My client receives the reply via the temp queue.
>>
>>
>> I have no need for Quality Of Service or persistence. So far for the
>> cleint
>> I have set the following properties to improve performance:
>>
>>   <bean id="connectionFactory"
>> class="org.springframework.jms.connection.SingleConnectionFactory">
>>     <property name="targetConnectionFactory">
>>       <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>>         <property name="brokerURL">
>>
>> <value>tcp://192.168.160.86:61616?jms.prefetchPolicy.queuePrefetch=100</value>
>>         </property>
>>         <property name="useAsyncSend"><value>TRUE</value></property>
>>         <property
>> name="optimizeAcknowledge"><value>TRUE</value></property>
>>       </bean>
>>     </property>
>>   </bean>
>>
>> Is optimizeAcknowledge related to Session.DUPS_OK_ACKNOWLEDGE?
> 
> I wouldn't worry about optimizeAcknowledge
> 
> You should make sure your producer is using non-persistent mode.
> 
> 
>> For the server side I have used the same properties for now:
>>
>>   <bean id="connectionFactory"
>> class="org.springframework.jms.connection.SingleConnectionFactory">
>>     <property name="targetConnectionFactory">
>>       <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>>         <property name="brokerURL">
>>
>> <value>tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=100</value>
>>         </property>
>>         <property name="useAsyncSend"><value>TRUE</value></property>
>>         <property
>> name="optimizeAcknowledge"><value>TRUE</value></property>
>>       </bean>
>>     </property>
>>   </bean>
>>
>>
>> The server and broker run on the same machine for this test but will not
>> in
>> production hence I have not bothered trying to embed the broker in the
>> server.
>>
>> Baiscally for this test my client is punching out about 1000 messages and
>> I
>> want to see how long it takes to get replies. At the moment I am pumping
>> out
>> about 1000 messages in about 2 seconds but it takes 20 seconds to get the
>> 1000 replies. I am obviously missing something here?? Any pointers would
>> be
>> great.
> 
> Are you using a pool of consumers to process the requests? Otherwise
> you are single-threading things which is kinda slow. Also I'd leave
> high prefetch values (say 5000 at least) on consumers on both sides.
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/Session.DUPS_OK_ACKNOWLEDGE-tf3016262.html#a8387795
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Session.DUPS_OK_ACKNOWLEDGE

Posted by James Strachan <ja...@gmail.com>.
On 1/15/07, Paul French <pa...@frenchiesystems.com> wrote:
>
> ActivemQ 4.1.0
>
>
> Where do I set Session.DUPS_OK_ACKNOWLEDGE this?

http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Connection.html#createSession(boolean,%20int)


> I'm trying to increase
> performance of the messaging layer and I'm going through the performance
> guide at
> http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html
> http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html
>
> I can send out a 1000 messages a second no problem but the rest of the
> messaging layer is very slow so I need some help here.
>
> My scenario is client creates many messages and sends async to the broker
> (one connection, one session). The client also creates a temporary queue to
> receive replies on. The client also starts a number of consumers to listen
> on the temp queue.
>
> A consumer consumes the messages and then replies by placing a message on
> the temporary queue.
>
> My client receives the reply via the temp queue.
>
>
> I have no need for Quality Of Service or persistence. So far for the cleint
> I have set the following properties to improve performance:
>
>   <bean id="connectionFactory"
> class="org.springframework.jms.connection.SingleConnectionFactory">
>     <property name="targetConnectionFactory">
>       <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>         <property name="brokerURL">
>
> <value>tcp://192.168.160.86:61616?jms.prefetchPolicy.queuePrefetch=100</value>
>         </property>
>         <property name="useAsyncSend"><value>TRUE</value></property>
>         <property name="optimizeAcknowledge"><value>TRUE</value></property>
>       </bean>
>     </property>
>   </bean>
>
> Is optimizeAcknowledge related to Session.DUPS_OK_ACKNOWLEDGE?

I wouldn't worry about optimizeAcknowledge

You should make sure your producer is using non-persistent mode.


> For the server side I have used the same properties for now:
>
>   <bean id="connectionFactory"
> class="org.springframework.jms.connection.SingleConnectionFactory">
>     <property name="targetConnectionFactory">
>       <bean class="org.apache.activemq.ActiveMQConnectionFactory">
>         <property name="brokerURL">
>
> <value>tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=100</value>
>         </property>
>         <property name="useAsyncSend"><value>TRUE</value></property>
>         <property name="optimizeAcknowledge"><value>TRUE</value></property>
>       </bean>
>     </property>
>   </bean>
>
>
> The server and broker run on the same machine for this test but will not in
> production hence I have not bothered trying to embed the broker in the
> server.
>
> Baiscally for this test my client is punching out about 1000 messages and I
> want to see how long it takes to get replies. At the moment I am pumping out
> about 1000 messages in about 2 seconds but it takes 20 seconds to get the
> 1000 replies. I am obviously missing something here?? Any pointers would be
> great.

Are you using a pool of consumers to process the requests? Otherwise
you are single-threading things which is kinda slow. Also I'd leave
high prefetch values (say 5000 at least) on consumers on both sides.

-- 

James
-------
http://radio.weblogs.com/0112098/