activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Laügt (JIRA) <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-520) AMQ crashes when an exception comes during the connection closure
Date Tue, 22 Oct 2013 15:15:45 GMT

    [ https://issues.apache.org/jira/browse/AMQCPP-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801899#comment-13801899
] 

Daniel Laügt commented on AMQCPP-520:
-------------------------------------

Probably two domains can be fixed:
  1) Before AMQCPP-463, FailoverTransport::handleTransportFailure() was multi-thread safe.
It is not the case after the changes done in AMQCPP-463.
  2) An exception is raised on reading data from IOTransport. The exception "Not supported
for SSL Sockets" is raised by OpenSSLSocket::shutdownInput(). This method is called by OpenSSLSocket::read()
when the read status is SSL_ERROR_ZERO_RETURN and the socket is not closed. 

Here is OpenSLL documentation about SSL_ERROR_ZERO_RETURN:
The TLS/SSL connection has been closed. If the protocol version is SSL 3.0 or TLS 1.0, this
result code is returned only if a closure alert has occurred in the protocol, i.e. if the
connection has been closed cleanly. Note that in this case SSL_ERROR_ZERO_RETURN does not
necessarily indicate that the underlying transport has been closed. 

> AMQ crashes when an exception comes during the connection closure
> -----------------------------------------------------------------
>
>                 Key: AMQCPP-520
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-520
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 3.6.0
>         Environment: Solaris 10 with gcc 3.4.6
>            Reporter: Daniel Laügt
>            Assignee: Timothy Bish
>            Priority: Minor
>              Labels: AMQCPP-463, Regression, from
>         Attachments: FailoverTransport.cpp.patch, test.cc
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> From one thread, an exception comes and FailoverTransport::handleTransportFailure ()
is called:
> activemq::transport::failover::CloseTransportsTask::add(const Pointer<Transport>
transport)
> activemq::transport::failover::FailoverTransport::handleTransportFailure(const decaf::lang::Exception
& error={...})
> activemq::transport::failover::FailoverTransportListener::onException(const decaf::lang::Exception
& ex={...})
> activemq::transport::TransportFilter::onException(const decaf::lang::Exception &
ex={...})
> activemq::wireformat::openwire::OpenWireFormatNegotiator::onException(const decaf::lang::Exception
& ex={...})
> activemq::transport::TransportFilter::onException(const decaf::lang::Exception &
ex={...})
> activemq::transport::inactivity::InactivityMonitor::onException(const decaf::lang::Exception
& ex={...})
> activemq::transport::TransportFilter::onException(const decaf::lang::Exception &
ex={...})
> activemq::transport::IOTransport::fire(decaf::lang::Exception & ex={...})
> activemq::transport::IOTransport::run()
> decaf::lang::Thread::run()
> From another thread, the amq connection is being closed. It destructs the FailoverTransport
without waiting that the first thread finishes to call handleTransportFailure():
> activemq::transport::failover::FailoverTransport::~FailoverTransport()
> activemq::transport::failover::FailoverTransport::`vector deleting destructor'(unsigned
int)
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::onDeleteFunc(activemq::transport::Transport
* value=0x02f307b0)
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::~Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>()
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::reset(activemq::transport::Transport
* value=0x00000000)
> activemq::transport::TransportFilter::~TransportFilter()
> activemq::transport::correlator::ResponseCorrelator::~ResponseCorrelator()
> activemq::transport::correlator::ResponseCorrelator::`vector deleting destructor'(unsigned
int)
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::onDeleteFunc(activemq::transport::Transport
* value=0x03ba6058)
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::~Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>()
> decaf::lang::Pointer<activemq::transport::Transport,decaf::util::concurrent::atomic::AtomicRefCounter>::reset(activemq::transport::Transport
* value=0x00000000)
> activemq::core::ActiveMQConnection::disconnect(__int64 lastDeliveredSequenceId=0)
> activemq::core::ActiveMQConnection::close()
> I don't have any simple test case as it is a race condition.
> I've attached a proposal patch.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message