Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of tabish121@gmail.com designates
 209.85.216.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id
         :mime-version:x-mailer:content-transfer-encoding;
        b=wHDULlHlIyk9zRrLHlZybz0XuhWbXfaVBQ55ilpSQFDBeqo6X2iGQh4p3Rrfg3oVJf
         EzBIzPDHWUujp193cCjeXHVFgXRg1R1T9I6XwLIl580mI7oIIe5NIymdgFeCmsjE6Avc
         0Bf5EuczD9OZ0vjtAMkW/NfEDyY4BeOMDipOE=
Subject: Re: DeadLock in CMS 3.1 ?
From: Timothy Bish <tabish121@gmail.com>
To: users@activemq.apache.org
In-Reply-To: <27564631.post@talk.nabble.com>
References: <27562260.post@talk.nabble.com>
	 <1265982360.2334.6.camel@localhost>  <27564631.post@talk.nabble.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 12 Feb 2010 09:58:02 -0500
Message-ID: <1265986682.2334.9.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 2010-02-12 at 06:46 -0800, Sodan wrote:
> Actually I were able to reproduce it every time, I started the app.
> Nothing much going on, but as soon I as recieved a message a create
> a session/producer from the replyto dest, then it will just hang there...
> maybe the other end (ie. the broker) is somehow faulty and dont return
> a response so createsession just hangs...
> 
> we restarted the broker and now it works... (until next time)...
> 
> should it throw an exception right away or after some time ?
> 
> Søren
> 

Its possible that your experiencing producer flow control from the
broker, see: http://activemq.apache.org/producer-flow-control.html

Regards
Tim.


> 
> Timothy Bish wrote:
> > 
> > On Fri, 2010-02-12 at 03:35 -0800, Sodan wrote:
> >> When lots of message are going on I suddenly sometimes get:
> >> 
> >> res = WaitForSingleObject( condition->semaphore, (DWORD)mills ); //
> >> forever
> >> ??
> >> hang here forever
> >> 
> >> lobbyserver.exe!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle
> >> * condition=0x098c9e18, __int64 mills=0x00000000ffffffff, __int64
> >> nanos=0x0000000000000000)  Line 110 + 0x10 bytes	C++
> >> lobbyserver.exe!decaf::internal::util::concurrent::ConditionImpl::wait(decaf::util::concurrent::ConditionHandle
> >> * condition=0x098c9e18)  Line 71 + 0x11 bytes	C++
> >> lobbyserver.exe!decaf::util::concurrent::Mutex::wait()  Line 95 + 0xf
> >> bytes
> >> C++
> >> lobbyserver.exe!decaf::util::concurrent::CountDownLatch::await()  Line 53
> >> +
> >> 0x17 bytes	C++
> >> lobbyserver.exe!activemq::transport::correlator::FutureResponse::getResponse() 
> >> Line 63	C++
> >> lobbyserver.exe!activemq::transport::correlator::ResponseCorrelator::request(const
> >> decaf::lang::Pointer<activemq::commands::Command,decaf::lang::AtomicRefCounter>
> >> & command={...})  Line 119 + 0x2d bytes	C++
> >> lobbyserver.exe!activemq::core::ActiveMQConnection::syncRequest(decaf::lang::Pointer<activemq::commands::Command,decaf::lang::AtomicRefCounter>
> >> command={...}, unsigned int timeout=0x00000000)  Line 611 + 0x32 bytes
> >> C++
> >> lobbyserver.exe!activemq::core::ActiveMQConnection::createSession(cms::Session::AcknowledgeMode
> >> ackMode=AUTO_ACKNOWLEDGE)  Line 149	C++
> >> 
> >> Søren
> >> 
> > 
> > Can you provide more information on this such as a small sample app that
> > demonstrates the issue.  I need more context into what you are doing
> > when this occurs before I can start to investigate.
> > 
> > Regards
> > 
> > 
> > -- 
> > Tim Bish
> > 
> > Open Source Integration: http://fusesource.com
> > ActiveMQ in Action: http://www.manning.com/snyder/
> > 
> > Follow me on Twitter: http://twitter.com/tabish121
> > My Blog: http://timbish.blogspot.com/
> > 
> > 
> > 
> 

-- 
Tim Bish

Open Source Integration: http://fusesource.com
ActiveMQ in Action: http://www.manning.com/snyder/

Follow me on Twitter: http://twitter.com/tabish121
My Blog: http://timbish.blogspot.com/