[ 
https://issues.apache.org/activemq/browse/AMQCPP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50579#action_50579
 ] 

Timothy Bish commented on AMQCPP-205:
-------------------------------------

As far as the original issue goes, I've not been able to repeat it at all.

>From the stack trace posted at looks at least for the CPP client side that the 
>client has sent a Message to the broker and is awaiting a response, and it 
>looks like there isn't a send time-out set so it just going to wait forever, 
>which is part of the flow control mechanism.  So on the client side it doesn't 
>look to me like there is anything wrong.  

I'm not sure what the error on the broker is related to though, if you can 
reproduce it, then it might be worth opening on issue.

> CmsTemplate testBasics test can hang
> ------------------------------------
>
>                 Key: AMQCPP-205
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-205
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Integration Tests
>    Affects Versions: 2.2.1, 2.2.2
>         Environment: CentOS / REHL
>            Reporter: Timothy Bish
>            Assignee: Timothy Bish
>             Fix For: 3.0
>
>         Attachments: cmstemplate.segfault-1.log.gz, receiving.187.log.gz
>
>
> Running the CmsTemplate integration tests in a loop can result in a hang.  
> The code appears to be deadlocked when two threads that share the same 
> instance of an ActiveMQSessionExecutor are run.  
> This snippet from a backtrace shows the case:
> {noformat}
> Thread 3 (Thread 1094732688 (LWP 15620)):
> #0  0x40000402 in __kernel_vsyscall ()
> #1  0x005ac266 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2  0x4056c327 in apr_thread_cond_wait (cond=0x86813a0, mutex=0x40912ae8) at 
> locks/unix/thread_cond.c:68
> #3  0x4031e458 in decaf::util::concurrent::Mutex::wait (this=0x409030c0, 
> millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:116
> #4  0x4031e13e in decaf::util::concurrent::Mutex::wait (this=0x409030c0) at 
> decaf/util/concurrent/Mutex.cpp:82
> #5  0x40238268 in activemq::core::ActiveMQSessionExecutor::run 
> (this=0x409030a8) at activemq/core/ActiveMQSessionExecutor.cpp:222
> #6  0x4030589f in decaf::lang::Thread::runCallback (self=0x858f488, 
> param=0x40902f08) at decaf/lang/Thread.cpp:121
> #7  0x4057aa1c in dummy_worker (opaque=0x858f488) at 
> threadproc/unix/thread.c:142
> #8  0x005a846b in start_thread () from /lib/libpthread.so.0
> #9  0x004ffdbe in clone () from /lib/libc.so.6
> Thread 2 (Thread 1098935184 (LWP 15621)):
> #0  0x40000402 in __kernel_vsyscall ()
> #1  0x005ac266 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2  0x4056c327 in apr_thread_cond_wait (cond=0x86813d8, mutex=0x40912ae8) at 
> locks/unix/thread_cond.c:68
> #3  0x4031e458 in decaf::util::concurrent::Mutex::wait (this=0x409030c0, 
> millisecs=4294967295) at decaf/util/concurrent/Mutex.cpp:116
> #4  0x4031e13e in decaf::util::concurrent::Mutex::wait (this=0x409030c0) at 
> decaf/util/concurrent/Mutex.cpp:82
> #5  0x40238268 in activemq::core::ActiveMQSessionExecutor::run 
> (this=0x409030a8) at activemq/core/ActiveMQSessionExecutor.cpp:222
> #6  0x4030589f in decaf::lang::Thread::runCallback (self=0x858f488, 
> param=0x40902f08) at decaf/lang/Thread.cpp:121
> #7  0x4057aa1c in dummy_worker (opaque=0x858f488) at 
> threadproc/unix/thread.c:142
> #8  0x005a846b in start_thread () from /lib/libpthread.so.0
> #9  0x004ffdbe in clone () from /lib/libc.so.6
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to