Are you using a non-zero wireFormat.maxInactivityDuration? This type of situation is exactly what it's intended to detect. On Dec 23, 2014 2:51 AM, "Marcel Meulemans" <m.meulem...@tkhinnovations.com> wrote:
> I have a question about what the expected behaviour of dropping a slow AMQP > consumer is/should be. I am using 5.11-SNAPSHOT. The behaviour I am > observing is as follows: > > - I have an AMQP (proton-c) client that is consuming messages from ActiveMQ > from a specific queue via a specific AMQP link. > - The client is on a different machine from ActiveMQ > - While device is correctly consuming messages turn off the wifi on the > AMQP machine (there are still messages in this queue). > - Obviously communication stops. > - Turn back on the wifi. > - ActiveMQ will have dropped the "slow" consumer: 2014-12-22 11:57:07,414 | > INFO | aborting slow consumer: ID:ubuntu-hp-54642-1418997390497-2:16:0:0 > for destination:queue://somequeue | > org.apache.activemq.broker.region.policy.AbortSlowConsumerStrategy | > ActiveMQ Broker[localhost] Scheduler > - Both computers still consider the TCP connection to be active (the > connection is still listed also by ActiveMQ > - On the client nothing happens: no messages are consumed anymore > (obviously), AMQP link is open on remote and local side. > > Currently I seem to be unable to recover from this situation because the > client does not know ActiveMQ has drop it as a consumer. I expected > ActiveMQ to close the AMQP link, or maybe even the session, after which > recovering would be fairly trivial. > > Any ideas? > > -- > Marcel >
