You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2010/01/18 16:36:44 UTC
[jira] Commented: (AMQCPP-277) Freeze when creating multiple
Consumers
[ https://issues.apache.org/activemq/browse/AMQCPP-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56975#action_56975 ]
Timothy Bish commented on AMQCPP-277:
-------------------------------------
I've not been able to reproduce this one yet.
One thing you could try is to not start the connection until after creating that amount of consumers. Each time you create a consumer and set a listener on it, it must stop message delivery for all consumers on the session which can be heavy process if there are a large number of consumers.
I'm going to keep trying to recreate the lockup.
> Freeze when creating multiple Consumers
> ---------------------------------------
>
> Key: AMQCPP-277
> URL: https://issues.apache.org/activemq/browse/AMQCPP-277
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.1
> Environment: Windows 7 x64, ActiveMQ Server 5.3, Java 6.0.17, Visual Studio 2008 SP1, Windows 7 SDK, APR 1.3.9
> Reporter: Eddie Fast
> Assignee: Timothy Bish
> Fix For: 3.2.0
>
>
> We create multiple MessageConsumers with different selectors. This can be upwards of 50 or so consumers per client.
> We recently upgraded to 3.1 from 2.2.2. We also upgraded our ActiveMQ Server to 5.3 from 5.2.
> After upgrading, we've been seeing random, but frequent freezing in our clients. I've narrowed it down to where it creates the MessageConsumer and calls setMessageListener();
> It seems to be stuck, waiting for a thread to join.
> I've modified the main.cpp to exhibit this behavior, but I've only been able to reproduce it randomly. It seems to happen more frequently if you stick a breakpoint on this line in Thread.cpp, Thread::join():
> Thread::join( INFINITE, 0 );
> Here's the callstack where it freezes, which is consistent in our clients as well as the main.cpp example:
> ntdll.dll!76fff871()
> [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
> ntdll.dll!76fff871()
> KernelBase.dll!75e20816()
> kernel32.dll!755b1138()
> activemq-cppd.dll!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle * condition=0x0239e0e0, __int64 mills=4294967295, __int64 nanos=0) Line 110 + 0x10 bytes C++
> activemq-cppd.dll!decaf::util::concurrent::Mutex::wait(__int64 millisecs=4294967295, int nanos=0) Line 124 + 0x20 bytes C++
> activemq-cppd.dll!decaf::lang::Thread::join(__int64 millisecs=4294967295, unsigned int nanos=0) Line 464 + 0x36 bytes C++
> activemq-cppd.dll!decaf::lang::Thread::join() Line 421 C++
> > activemq-cppd.dll!activemq::threads::DedicatedTaskRunner::shutdown() Line 83 C++
> activemq-cppd.dll!activemq::core::ActiveMQSessionExecutor::stop() Line 110 C++
> activemq-cppd.dll!activemq::core::ActiveMQSession::stop() Line 807 C++
> activemq-cppd.dll!activemq::core::ActiveMQConsumer::setMessageListener(cms::MessageListener * listener=0x0018fe0c) Line 523 C++
> vs2005-activemq-example.exe!HelloWorldConsumer::run() Line 247 + 0x5b bytes C++
> activemq-cppd.dll!decaf::lang::ThreadProperties::runCallback(decaf::lang::ThreadProperties * properties=0x01df7f68) Line 133 + 0x11 bytes C++
> activemq-cppd.dll!`anonymous namespace'::threadWorker(void * arg=0x01df7f68) Line 204 + 0x9 bytes C++
> msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
> msvcr90d.dll!_threadstartex(void * ptd=0x01dfafd8) Line 331 C
> To modify main.cpp, it's pretty simple. Instead of creating 1 MessageConsumer in HelloWorldConsumer::run(), I've created 50:
> {quote}
> // put this line with the class variables
> std::vector<MessageConsumer*> consumers;
> for ( int i = 0; i < 50; i++ )
> {{
> // Create a MessageConsumer from the Session to the Topic or Queue
> consumers.push_back( session->createConsumer( destination ) );
> consumers.back()->setMessageListener( this );
> }}
> {quote}
> I'm using the standard .conf for the server. I've reverted to 2.2.2 and have no issues.
> Any ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.