On 03/18/2014 01:26 PM, davery wrote:
Follow up in case anyone else finds this thread.
Based on empirical data, the broker stopped dispatching messages to the
consumer due to a time sync/TTL issue. The consumer was correctly waiting in
the apr_socket_recv() method.
I found that if the broker and consumer (on separate machines) had a time
sync difference greater than the TTL the broker stopped dispatching messages
to the consumer.
Has anyone else seen a similar problem?
davery wrote
I was able to reproduce the problem and get a stack trace for the hanging
thread. It appears to be waiting for data from the ActiveMQ broker.
#0 0xb76f4424 in __kernel_vsyscall ()
#1 0xb76e09db in read () from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb6bee435 in read (__nbytes=
<optimized out>
, __buf=0xb6005838, __fd=
<optimized out>
)
at /usr/include/i386-linux-gnu/bits/unistd.h:45
#3 apr_socket_recv (sock=0xb6003888, buf=0xb6005838 "", len=0xb41fee38)
at network_io/unix/sendrecv.c:81
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-consumers-stop-accepting-messages-tp4678923p4679174.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
This is quite common. If you cannot sync the machines to an NTP server
then you can try using the TimeStampBrokerPlugin to alter the timestamp
so that the message doesn't expire prematurely.
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/
