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
