[
https://issues.apache.org/activemq/browse/AMQCPP-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47333#action_47333
]
Alexander Martens commented on AMQCPP-205:
------------------------------------------
Hi there.
Running the CMSTemplate alone, with apr-1.3.3 and ActiveMQ 5.1 locked up (again
with threads 2 and 3) during loop #16, in less than 5 minutes.
The broker has the attribute persistent="false" and the server is being
restarted between tests, i.e.: nothing new, just a few details for anyone
joining this thread now.
Timothy, I'm surprised by the loop number: I'm wondering if going back to apr
1.3.3 has anything to do with it or it was just good luck. I'll manage to have
a few more tries, to confirm the change in the lock probability.
> 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: 2.3
>
> Attachments: 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.
