<div dir="ltr">You cannot share reply queues across instances; unlike JMS, AMQP has no notion of a message selector to choose messages from a queue, so each instance needs its own reply queue.<div><br></div><div>When the reply goes to the wrong instance, the originating instance thread will be suspended for (default) 5 seconds (modifiable by setting <font face="courier new, monospace">replyTimeout</font>).</div>
<div><br></div><div>You can increase throughput by increasing the <font face="courier new, monospace">concurrency</font> on the listener containers.</div><div><br></div><div>The upcoming 1.3 release of spring-AMQP allows the concurrency to vary on demand; with 1.2.x you have to stop/start the container to change the concurrency.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 1:07 PM, tgv amni <span dir="ltr"><<a href="mailto:tgvt53@gmail.com" target="_blank">tgvt53@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><p class="MsoNormal">Hi�</p>
<p class="MsoNormal">We are beginners in rabbitmq. We use rabbitmq 3.2.2. We use spring amqp.</p><p class="MsoNormal"><br></p><p class="MsoNormal">I
recently observed an issue with multiple listeners on the same reply queue when
performance testing�</p>
<p class="MsoNormal">our application.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Here is the test scenario:</p>
<p class="MsoNormal">50 Concurrent users post a request to Service F to create an
entity A. The message contains a user id and a timestamp. Each concurrent user
posts roughly two messages per second.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">F publishes this message to a non-durable queue via a topic
exchange (using convertSendAndReceive) and waits for the response on a fixed
reply queue ReplyQ1.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Service A picks up this message and creates this entity
(basically an entry in a table) after</p>
<p class="MsoNormal">validating that the user id wihin that message is valid.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">For the validation, Service A sends this message to another
non-durable queue via a topic exchange (convertSendAndReceive) and waits for a
response on�</p>
<p class="MsoNormal">another fixed reply queue, ReplyQ2.�</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">A validating service V picks up this user id, validates it
(basically a select from a db table) and then sends the response back to
ReplyQ2.</p>
<p class="MsoNormal">Service A picks this up, based on the message, creates the
entity and then sends response to ReplyQ1.�</p><p class="MsoNormal"><br></p><p class="MsoNormal">All messages are non-persistent. No concurrency or prefetch settings configured on the listeners.�<br></p>
<p class="MsoNormal">�</p>
<p class="MsoNormal"><b>CreateEntity A Request -> Service F -> Q1 ->
Service A -> Q2 - Service V</b></p>
<p class="MsoNormal"><b>Service V-> ReplyQ2 -> Service A (creates entity A if
user valid) -> ReplyQ1 -> Service F</b></p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">F, A and V all live within the same tomcat instance. When a
second tomcat instance was started with service A and V, I started to notice
warning messages in tomcat logs:</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal"><b>WARN : org.springframework.amqp.rabbit.core.RabbitTemplate -
Reply received after timeout for b3fd4f57-0403-4704-8f16-8c3055ca0cd9</b></p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">It looked like messages were not picked up by the correct
listener from the validation response queues. Rabbitmq logs did not show any errors. From the management console i saw 40-60 messages always staying in ready state �in Q1, with a few in unacked state.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Response times were very high for this create Entity A request
(10 seconds) and only about 5 transactions were processed per second. Tests
were run in AWS on m1.large instances.</p>
<p class="MsoNormal">High response time was not caused by network latency. Network latency was really small.�</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">On testing with separate reply queues for the user id
validation response,�</p>
<p class="MsoNormal">(ReplyQ21 and ReplyQ22 instead of ReplyQ2), response times
improved (1 second) and more transactions (roughly 70) were processed per
second.�</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Is this a good design approach for this scenario? Or is
there a better way to handle this ?</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Please let me know if you need any other
information.</p>
<p class="MsoNormal">�</p>
<p class="MsoNormal">Thanks.</p></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>