activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Dropping slow AMQP consumer behaviour
Date Tue, 23 Dec 2014 14:46:40 GMT
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.meulemans@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message