[
https://issues.apache.org/activemq/browse/AMQCPP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45260#action_45260
]
sergey.emantayev edited comment on AMQCPP-165 at 8/31/08 8:09 AM:
------------------------------------------------------------------
I'd suggest following fix in closeResource:
{quote}
} else if( typeid( *resource ) == typeid( OpenWireSessionInfo ) ) {
OpenWireSessionInfo* session =
dynamic_cast<OpenWireSessionInfo*>(resource);
// Sergey: <<<<<<
if (!session->getSessionInfo())
{
return;
}
// >>>>>>>
dataStructure = session->getSessionInfo()->getSessionId();
{quote}
Thanks
Sergey
was (Author: sergey.emantayev):
I'd suggest following fix in closeResource:
} else if( typeid( *resource ) == typeid( OpenWireSessionInfo ) ) {
OpenWireSessionInfo* session =
dynamic_cast<OpenWireSessionInfo*>(resource);
// Sergey: <<<<<<
if (!session->getSessionInfo())
bq.
{
return;
}
// >>>>>>>
dataStructure = session->getSessionInfo()->getSessionId();
Thanks
Sergey
> Core Dump on reconnect/open queue
> ---------------------------------
>
> Key: AMQCPP-165
> URL: https://issues.apache.org/activemq/browse/AMQCPP-165
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 2.1.1
> Environment: Red Hat Linux 2.4.x
> Reporter: pfid
> Assignee: Nathan Mittler
> Fix For: 2.2
>
> Attachments: sample.tar.gz
>
>
> our activemq application core dumped several times during the last days when
> the connection to the broker was lost. each time it was either caused by the
> broker beeing restartet or write attempts failing (see exception below).
> in both cases the application catches a CMS exception, closes all queues and
> tries to re-open them after 60s. all activemq objects are destroyed after
> closing (see cleanup() from web example).
> the core dumps seemed to happen when the application trys to re-open the
> connection, but fails because the broker is still unreachable. here is the
> backtrace:
> <quote>
> #0 activemq::connector::openwire::OpenWireConnector::closeResource
> (this=0x8b4a268, resource=0x8b4dde0) at
> activemq/connector/openwire/OpenWireConnector.cpp:1200
> #1 0x080da6fc in activemq::connector::BaseConnectorResource::close
> (this=0x8b4dde0) at activemq/connector/BaseConnectorResource.cpp:59
> #2 0x0812ff50 in ~OpenWireSessionInfo (this=0x8b4dde0) at
> OpenWireSessionInfo.h:56
> #3 0x0812d0c4 in
> activemq::connector::openwire::OpenWireConnector::createSession
> (this=0x8b4dde0, ackMode=cms::Session::AUTO_ACKNOWLEDGE)
> at activemq/connector/openwire/OpenWireConnector.cpp:281
> #4 0x080e86c1 in activemq::core::ActiveMQConnection::createSession
> (this=0x8b4ded0, ackMode=137247624) at activemq/core/ActiveMQConnection.cpp:98
> #5 0x08059c19 in ActiveMqQueue::open (this=0x8b1d6b0, aQueueName=0x8ab925c
> "outqueue", aMode=ActiveMqQueue::modeWrite, aListenMode=0) at
> activemqqueue.cc:335
> </quote>
> Debuggin shows that at activemq/connector/openwire/OpenWireConnector.cpp:1200
> 1200: dataStructure = session->getSessionInfo()->getSessionId();
> the session object is null, the previously dyn-casted resource object however
> is not null:
> <quote>
> (gdb) p session
> $1 = (activemq::connector::openwire::OpenWireSessionInfo *) 0x0
> (gdb) p resource
> $2 = (class activemq::connector::ConnectorResource *) 0x8b4dde0</quote>
> (corrupt memory?)
> Exception when write attempts fail:
> <quote>No valid response received for command: Begin Class =
> ActiveMQTextMessage Begin Class = ActiveMQMessageBase Value of ackHandler =
> 0 Value of redeliveryCount = 0 Value of properties = Begin Class
> PrimitiveMap: Begin Class PrimitiveMap: Begin Class = Message Value of
> Message::ID_MESSAGE = 0 Value of ProducerId is Below: Begin Class =
> ProducerId Value of ProducerId::ID_PRODUCERID = 123 Value of ConnectionId =
> 0c00f32b-2269-4e0f-ace1-13fd0414b4b5 Value of Value = 0 Value of SessionId
> = 0 No Data for Class BaseDataStructure End Class = ProducerId Value of
> Destination is Below: Begin Class = ActiveMQQueue Begin Class =
> ActiveMQDestination Value of exclusive = false Value of ordered = false
> Value of advisory = false Value of orderedTarget = coordinator Value of
> physicalName = ffs_out Value of options = Begin Class
> activemq::util::Properties: End Class activemq::util::Properties: No Data
> for Class BaseDataStructure End Class = ActiveMQDestination End Class =
> ActiveMQQueue Value of TransactionId is Below: Object is NULL Value of
> OriginalDestination is Below: Object is NULL Value of MessageId is Below:
> Begin Class = MessageId Value of MessageId::ID_MESSAGEID = 110 Value of
> ProducerId is Below: Begin Class = ProducerId Value of
> ProducerId::ID_PRODUCERID = 123 Value of ConnectionId =
> 0c00f32b-2269-4e0f-ace1-13fd0414b4b5 Value of Value = 0 Value of SessionId
> = 0 No Data for Class BaseDataStructure End Class = ProducerId Value of
> ProducerSequenceId = 4 Value of BrokerSequenceId = 0 No Data for Class
> BaseDataStructure End Class = MessageId Value of OriginalTransactionId is
> Below: Object is NULL Value of GroupID = Value of GroupSequence = 0
> Value of CorrelationId = Value of Persistent = 1 Value of Expiration =
> 1201683817204 Value of Priority = 4 Value of ReplyTo is Below: Object is
> NULL Value of Timestamp = 1201676617204 Value of Type = Value of
> Content[0] = , check broker.</quote>
> Versions:
> Activemq-cpp-2.1.1
> ActiveMq Broker 4.1.1
> the application handles 17 write-mode queues, with a rather low
> messages/second rate.
> Using 5.0.0 broker instead of 4.1.1 would most likely solve this problem,
> since the failed write attempts problem only occurs with 4.1.1 broker (i
> reported this bug before, but it seemed like no one was interested in taking
> care of it). however, the broker 5.0.0 won't start with preconfigured JAAS
> queues, so its not an option and we have to stick with 4.1.1. i will try the
> latest snapshot these days, however i dont feel good when using a snapshot
> server in production environment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
