activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tab...@twcny.rr.com>
Subject Re: Access Violation - activemq::io::SocketInputStream::read - The connection is broken
Date Sat, 30 Jun 2007 13:35:26 GMT
You should try the trunk code, there were some crash fixes made for 
shutdown since 2.0.1 was released.

huntc wrote:
> Hi there,
>
> I'm getting some sort of access violation/segmentation fault if I have a
> connection open and I shut the broker down. I think that the abend is the
> result of some problem when the session is closed. I'm using v.2.0.1.
>
> A note on convention for the following: I'm using boost's shared_ptr class
> to manage my heap allocations.
>
> On with the story:
>
> An exception is raised and my handler captures it thus:
>
> void JMSSubscribeIFeatureSourceImp::onException(const CMSException&
> inException)
> {
>     cerr << BUNDLE_IDENTIFIER " - " << inException.getMessage() <<
endl;
>
>     {
>         mJMSConnectedMutex.Lock();
>         MutexUnlockSentry theInitedUnlocker(mJMSConnectedMutex);
>
>         mJMSConnected = false;  // Better had try and re-establish the
> connection
>     }
> }
>
> When I next try and send a message, if the connection is signaled as closed
> then I attempt to clean up and re-open the connection. Thus:
>
> void JMSSubscribeIFeatureSourceImp::MaintainJMSConnection() throw()
> {
>     {
>         mJMSConnectedMutex.Lock();
>         auto_ptr<MutexUnlockSentry> theUnlockerP(new
> MutexUnlockSentry(mJMSConnectedMutex));
>         
>         if (!mJMSConnected)
>         {
>             try
>             {
>                 // Ensure any connection that was previously established is
> now gone
> 				
> 				CloseJMSConnection();
>                 
>                 {
>                     // Create a ConnectionFactory
>                     auto_ptr<ActiveMQConnectionFactory>
> theConnectionFactoryP(new ActiveMQConnectionFactory());
>                     
>                     // Create a Connection
>                     mConnectionP =
> shared_ptr<Connection>(theConnectionFactoryP->createConnection());
>                 }
>                 
>
>                 // Indicate that we're now connected
>                 mJMSConnected = true;
>                 theUnlockerP.reset();   // Free the lock in case anything
> subsequently causes a problem
>                                         // and our exception listener is
> called.
>                 
>                 // Start up the connection and listen in on problems
>                 mConnectionP->start();
>                 mConnectionP->setExceptionListener(this);
>
>                 // Create a Session
>                 mSessionP =
> shared_ptr<Session>(mConnectionP->createSession(Session::AUTO_ACKNOWLEDGE));
>
>                 // Create the destination (Topic or Queue)
>                 mDestinationP =
> shared_ptr<Destination>(mSessionP->createTopic(GetTopicName()));
>
>                 // Create a MessageConsumer from the Session to the Topic
>                 mConsumerP =
> shared_ptr<MessageConsumer>(mSessionP->createConsumer(mDestinationP.get()));
>
>                 mConsumerP->setMessageListener(this);
>                 
>             }
>             catch (const CMSException& inException)
>             {
>                 cerr << BUNDLE_IDENTIFIER " - During connection - " <<
> inException.getMessage() << endl;
>             }
>             catch (const bad_alloc&)
>             {
>                 cerr << BUNDLE_IDENTIFIER " - bad alloc when attempting to
> get factory" << endl;
>             }
>         }
>     }
> }
>
> My close connection routine looks like this (I've been explicit closing
> things in the reverse order to which they're opened - I should just be able
> to reset the connection shared ptr causing a dealloc and that's all that is
> required. However by stepping through the below I find that my problem
> occurs during the mSessionP->close()):
>
> void JMSSubscribeIFeatureSourceImp::CloseJMSConnection() throw()
> {
>
> 	if (mConsumerP.get() != 0)
> 	{
> 		try
> 		{
> 			mConsumerP->setMessageListener(0);
> 		}
> 		catch (const CMSException&)
> 		{}
> 		
> 	}
>
> 	if (mSessionP.get() != 0)
> 	{
> 		try
> 		{
> 			mSessionP->close();
> 		}
> 		catch (const CMSException&)
> 		{}
> 		
> 	}
> 	
> 	if (mConnectionP.get() != 0)
> 	{
> 		try
> 		{
> 			mConnectionP->setExceptionListener(0);
> 		}
> 		catch (const CMSException&)
> 		{}
>
> 		try
> 		{
> 			mConnectionP->stop();
> 		}
> 		catch (const CMSException&)
> 		{}
> 		
> 		try
> 		{
> 			mConnectionP->close();
> 		}
> 		catch (const CMSException&)
> 		{}
> 		
> 	}
>
>     mConsumerP.reset();
>     mDestinationP.reset();
> 	mSessionP.reset();
> 	mConnectionP.reset();
> }
>
> The most interesting point to note is that the problem does not occur on my
> Intel Quad Xeon Mac OS X machine; only on my slow old PowerBook G4. I'm thus
> suspecting a race condition.
>
> Any thoughts before I investigate this further?
>
> Kind regards,
> Christopher
>   


Mime
View raw message