semog wrote:
>
> I'll try and take a look again at some of the threading code to see if
> I can find any obvious issues.
>
I appreciate it. I don't have much for you right now, but we have a
development system where the problem occurs frequently. When I attach the
debugger to our windows service, I see there are 20 threads on the
ReadInt32() line:
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.OpenWire.OpenWireBinaryReader.ReadInt32()
Line 132
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.OpenWire.OpenWireFormat.Unmarshal(System.IO.BinaryReader
dis = {Apache.NMS.ActiveMQ.OpenWire.OpenWireBinaryReader}) Line 218
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.Transport.Tcp.TcpTransport.ReadLoop()
Line 300
There is 1 thread on this line:
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.Dispatcher.Dequeue(System.TimeSpan
timeout = {System.TimeSpan}) Line 136
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.MessageConsumer.Receive(System.TimeSpan
timeout = {System.TimeSpan}) Line 108
And there are 15 threads on this line:
Apache.NMS.ActiveMQ.dll!Apache.NMS.ActiveMQ.DispatchingThread.MyThreadFunc()
Line 150
For the last one, the line is "m_event.WaitOne();"
Here's another interesting observation: I also have the JMX console
running, and use it to monitor the connections. When I attach the debugger
to our windows service, within about 30 seconds I can see that some of the
connections in the JMX console disappear, and then reappear shortly after.
That last part is not surprising because there is reconnect logic in our
service. However, when this happens, the messages start flowing again.
That seems to indicate to me that the threads were in fact deadlocked and
that caused the messages to get "stuck"
--
View this message in context:
http://www.nabble.com/thread-deadlock-issue-in-NMS-tp20180687p20270315.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
