Handle Stale Connections on Clients

Jerry Kuch-2 wrote

Hi, Monish:

If you're using the naked Java client, you'll have to implement your own
reconnection logic.  If you're using Spring AMQP there's some helper code
that wraps your connections with some retry logic for you.

Best regards,
Jerry

thanks much Jerry for such a prompt reply. I would love to re-use
spring-amqp and use the wrapped connection( it seems CachedConnectionFactory
+ SimpleListenerContainer ). 
what i am wondering for a simple amqp client that simply wants to re-connect
when a broker shutsdown, is there any way i can re-initialize all my
reply-queues( i have uuids associated with them), channels (wrapped channel
objects associated with connections) without having to re-write the code
with spring-amqp?

sorry to be presume that you would know the answer to this.....but a simple
logic/example would be great of how to go about it. 
the spring-amqp project seems to be quite complicated as it seems to have
logic for transactions ( also it's not entirely clear to me if i need to
write a listener container or just register a shutdownlistener etc).

thanks and regards,
-monish

--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Handle-Stale-Connections-on-Clients-tp20687p20721.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

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

See
http://static.springsource.org/spring-amqp/docs/1.1.1.RELEASE/reference/html/#d0e999

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

--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Handle-Stale-Connections-on-Clients-tp20687p20725.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Handle Stale Connections on Clients

Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients

Re: Handle Stale Connections on Clients