<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sorry for the delay.<br>
<br>
The current spring-amqp (1.1.1) now supports a 'fixed' reply queue
for request/reply scenarios.<br>
<br>
See<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://static.springsource.org/spring-amqp/docs/1.1.1.RELEASE/reference/html/#request-reply">http://static.springsource.org/spring-amqp/docs/1.1.1.RELEASE/reference/html/#request-reply</a><br>
<br>
We added this specifically for the performance impact you cite.<br>
<br>
Gary<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/11/2012 05:38 PM, cogitate wrote:<br>
</div>
<blockquote cite="mid:1342042707718-20725.post@n5.nabble.com"
type="cite">
<pre wrap="">Thanks Gary!
i also use spring-amqp and amqp inbound listener in spring-integration.
however, my issue is with reply-queue implementation of spring-amqp. i need
pre-made reply-queues that can be re-used (setup by configuration) even for
RPC semantics. i believe spring-amqp for RPC uses anonymous reply-queues and
also does consumer.cancel(benchmarks showed a 5ms delay for this on 24 core
cpu with broker and client running on the same box), which turns out to have
performance impact. thus, this rules out use of RabbitTemplate ( i wish it
had a way to use pre-made reply-queues that could be re-used).
thus, my wrappers around raw rabbitmq apis and even if i use
CachingConnectionFactory, i'd need to register a callback listener to
re-register my channels and reply-queues.
will definitely look at RabbitAdmin to learn how to do this.
thanks and regards,
-monish
Gary Russell wrote
</pre>
<blockquote type="cite">
<pre wrap="">
See
<a class="moz-txt-link-freetext" href="http://static.springsource.org/spring-amqp/docs/1.1.1.RELEASE/reference/html/#d0e999">http://static.springsource.org/spring-amqp/docs/1.1.1.RELEASE/reference/html/#d0e999</a>
It shouldn't take much heavy lifting to use spring-amqp instead of the raw
apis, and it will take care of reconnecting, setting up queues etc, via
the ConnectionListener callback in the RabbitAdmin class.
On the receiving side, you don't have to write any special listeners etc
to use spring-amqp; you can just write your code as a POJO and the
container uses an adapter to call your code. On the outbound side just use
a RabbitTemplate; in most cases you can use high-level APIs, while still
having access to the low level APIs (channel) if you ever need them.
If you can't move to spring-amqp, you might be able to leverage some of
the code from RabbitAdmin.
Gary
</pre>
</blockquote>
<pre wrap="">
--
View this message in context: <a class="moz-txt-link-freetext" href="http://rabbitmq.1065348.n5.nabble.com/Handle-Stale-Connections-on-Clients-tp20687p20725.html">http://rabbitmq.1065348.n5.nabble.com/Handle-Stale-Connections-on-Clients-tp20687p20725.html</a>
Sent from the RabbitMQ mailing list archive at Nabble.com.
_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>