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
#4 0xb73f3d80 in decaf::internal::net::tcp::TcpSocket::read
(this=0xb6001260,
buffer=0xfffffe00 <Address 0xfffffe00 out of bounds>, size=8192,
offset=-1241491400, length=-1219801168)
at decaf/internal/net/tcp/TcpSocket.cpp:649
#5 0xb73f4cfb in
decaf::internal::net::tcp::TcpSocketInputStream::doReadArrayBounded
(this=0xb60012c0, buffer=0xb6005838 "",
size=8192, offset=0, length=8192) at
decaf/internal/net/tcp/TcpSocketInputStream.cpp:108
#6 0xb742a01e in decaf::io::InputStream::doReadArray (this=0xb60012c0,
buffer=0xb6005838 "", size=8192)
at decaf/io/InputStream.cpp:138
#7 0xb742a2d2 in decaf::io::InputStream::read (this=0xb60012c0,
buffer=0xb6005838 "", size=8192) at decaf/io/InputStream.cpp:72
#8 0xb7420f74 in decaf::io::BufferedInputStream::bufferData
(this=0xb60016b0, inputStream=0xb60012c0,
buffer=@0xb41ff02c: 0xb6005838 "") at
decaf/io/BufferedInputStream.cpp:326
#9 0xb7421581 in decaf::io::BufferedInputStream::doReadArrayBounded
(this=0xb60016b0, buffer=0xb600151a "", size=4, offset=0,
length=4) at decaf/io/BufferedInputStream.cpp:228
#10 0xb742a162 in decaf::io::InputStream::read (this=0xb60016b0,
buffer=0xb600151a "", size=4, offset=0, length=4)
at decaf/io/InputStream.cpp:84
#11 0xb742582d in decaf::io::DataInputStream::readAllData (this=0xb6001508,
buffer=0xb600151a "", length=4)
at decaf/io/DataInputStream.cpp:492
#12 0xb7425b41 in decaf::io::DataInputStream::readInt (this=0xb6001508) at
decaf/io/DataInputStream.cpp:124
#13 0xb7379f22 in activemq::wireformat::openwire::OpenWireFormat::unmarshal
(this=0xb6003740, transport=0xb60011b0, dis=0xb6001508)
at activemq/wireformat/openwire/OpenWireFormat.cpp:245
#14 0xb73114be in activemq::transport::IOTransport::run (this=0xb60011b0) at
activemq/transport/IOTransport.cpp:246
#15 0xb743f07b in decaf::lang::ThreadProperties::runCallback
(properties=0xb6000798) at decaf/lang/Thread.cpp:137
#16 0xb743d681 in (anonymous namespace)::threadWorker (arg=0xb6000798) at
decaf/lang/Thread.cpp:190
#17 0xb76d9d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#18 0xb6d53bae in clone () from /lib/i386-linux-gnu/libc.so.6
gtully wrote
> sorry, i miss read "client side ack", it is not needed.
>
> On 13 March 2014 16:47, davery <
> d_avery@
> > wrote:
>> No, I didn't think that was required when the session is in auto
>> acknowledgement mode.
>>
>> From: gtully [via ActiveMQ] [mailto:
> [email protected]
> ]
>> Sent: Thursday, March 13, 2014 9:41 AM
>> To: Avery, Dave
>> Subject: Re: ActiveMQ consumers stop accepting messages
>>
>> and the app does message.acknowledge() every now and then?
>>
>> On 13 March 2014 15:52, davery <[hidden
>> email]</user/SendEmail.jtp?type=node&node=4679023&i=0>>
>> wrote:
>>> Client side ack is set to auto acknowledge
>>>
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ActiveMQ-consumers-stop-accepting-messages-tp4678923p4679058.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
