activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From spamtrap <nospam.1.friedbad...@spamgourmet.com>
Subject Re: Program blocking waiting for a lock
Date Fri, 09 Oct 2015 15:34:26 GMT
On Fri, 9 Oct 2015 11:03:10 -0400, Timothy Bish
<tabish121@gmail.com> wrote:

>On 10/09/2015 10:56 AM, spamtrap wrote:
>> On Fri, 9 Oct 2015 10:49:51 -0400, Timothy Bish
>> <tabish121@gmail.com> wrote:
>>
>>> On 10/09/2015 10:37 AM, spamtrap wrote:
>>>> On Mon, 21 Sep 2015 15:34:17 +0100, spamtrap
>>>> <nospam.1.friedbadger@spamgourmet.com> wrote:
>>>>
>>>>> ActiveMQ-CPP 3.9.0
>>>>>
>>>>> A program is blocking waiting for a lock:
>>>>>
>>>>> #0  0x000000367980b5bc in pthread_cond_wait@@GLIBC_2.3.2 ()
>>>>>   from /lib64/libpthread.so.0
>>>>> #1  0x00007fcab6c6c006 in (anonymous namespace)::doMonitorEnter (
>>>>>    monitor=0x26f63b0, thread=0x2605960)
>>>>>    at decaf/internal/util/concurrent/Threading.cpp:662
>>>>> #2  0x00007fcab6cf345b in decaf::util::concurrent::Lock::lock (
>>>>>    this=0x7fffe1a00890) at decaf/util/concurrent/Lock.cpp:54
>>>>> #3  0x00007fcab6cf3575 in decaf::util::concurrent::Lock::Lock (
>>>>>    this=<value optimized out>, object=<value optimized out>,
>>>>>    intiallyLocked=<value optimized out>) at
>>>>> decaf/util/concurrent/Lock.cpp:32
>>>>> #4  0x00007fcab69f2293 in
>>>>> activemq::core::FifoMessageDispatchChannel::stop (
>>>>>    this=0x26c2c50) at
>>>>> activemq/core/FifoMessageDispatchChannel.cpp:123
>>>>>
>>>>> How can I find out what is holding onto this lock?
>>>> I could really do with some help here.  I am trying to close a
>>>> consumer and it hangs forever.
>>> Your best bet is to create a test case that reproduces the problem.  A
>>> stack trace from one thread is not enough to even guess what is going on
>>> in your application here so it would be hard for anyone to offer any
>>> meaningful help.
>> This is not easy because it's very difficult to reproduce the problem
>> and I'm really not very sure what triggers it, but it does happen on a
>> client's system.  In general terms is it safe to close a consumer
>> object at any time?  And how can I find out what is holding onto the
>> lock?
>>
>>
>>
>>
>You can use GDB to view the threads and see what is going on. 

I have ;-)

> Could be
>your application in hung in an onMessage call and cannot complete the
>close call until that completes but that is just speculation. 

IIRC all the threads were waiting in pthread_cond_wait or similar (and
there are a very large number of threads in this application). It
shouldn't be hanging in an onMessage call since this method hands off
the processing to other threads. I don't know when I'll be able to
reproduce it again.  If I can find out which thread is holding onto
the lock that would be a start.



Mime
View raw message