Don't set maxInactivityDuration at all - then at least the clients
will get cleaned up - when they disapear (the default is 30000ms) -
which is actually the interval between keep alives if there's no
activity. With the default - the broker will eventually detect the
client is dead after about 1min. If you require it sooner - use a
smaller maxInactivityDuration value.
On 11 Jul 2008, at 08:23, Borer Reynald wrote:
On 10 Jul 2008, at 15:00, Rob Davies wrote:
On 10 Jul 2008, at 13:01, Borer Reynald wrote:
Hello,
I am using activeMQ for one of our projects where a Java applet is
used
to consume messages from JMS queues. During our tests, we discovered
that the number of consumers for each queue was not corresponding to
the
number of connected clients but was way higher (not everytime
indeed,
but it seems that sometimes some clients do not disconnect properly
from
the server because maybe the applets are killed, and the number of
consumers is not decremented...). I double checked the values
displayed
in the admin web page with the ones available through JMX to be
sure,
and they were the same.
Is there a way to purge those dead consumers ? It does not seems to
produce some loss of messages, so I guess that those consumers are
correctly detected as invalid in the server. Maybe they are even
deleted
and the number is not correctly set ?
Thanks in advance for your answers,
Reynald Borer
which transport protocol are you using ? - there are options on some
of the transports (like tcp) - for specifying maxInactivityDuration -
see
http://activemq.apache.org/configuring-wire-formats.html
cheers,
Rob
Rob Davies
'Go further faster with Apache Camel!'
http://rajdavies.blogspot.com/
Hi Rob,
Thanks for your answer. I am indeed using the tcp transport, setting
the
maxInactivityDuration to 0 because I need to keep a constant
connection
to consume immediately new messages (that is, I have registered a
message listener on a queue to process messages). Is this the correct
way of using activeMQ for my purpose or is there a better way to avoid
maxInactivityDuration set explicitly to zero ?
Regards,
Reynald
