[
https://issues.apache.org/activemq/browse/AMQCPP-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38038
]
Albert Strasheim commented on AMQCPP-59:
----------------------------------------
Okay, figured it out. It was an error on our end. We have a class that contains
a connection, session and consumer to deal with the Stomp selector limitations
and we were calling close on this consumer in our class's destructor (this is
where the unexpected exception came from) instead of just deleting it so that
AMQCPP could handle the exception.
> Exception is thrown when destroying consumer after connection failure
> ---------------------------------------------------------------------
>
> Key: AMQCPP-59
> URL: https://issues.apache.org/activemq/browse/AMQCPP-59
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Albert Strasheim
> Assigned To: Nathan Mittler
> Fix For: 2.0
>
>
> Brought over from AMQCPP-46.
> In a program that reconnects when it detects a connection failure using an
> exception listener, there seem to be two different places where exceptions
> can originate.
> In most cases when I shut down the broker and the exception listener fires
> properly and I can clean up everything (without deletes throwing exceptions),
> the stack trace that gets printed on the console looks like this:
> {noformat}
> WARNING: activemq::io::SocketInputStream::read - The connection is broken
> FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 137
> FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
> FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 216
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 120
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 71
> FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
> {noformat}
> The message is printed twice with different tids, from the two threads that
> are active.
> Sometimes when I shut down the broker and the exception handler fires and I
> clean up everything but then the consumer's destructor throws an exception.
> In that case, the stack trace that is printed looks like this:
> {noformat}
> WARNING: activemq::io::SocketInputStream::read - An existing connection was
> forcibly closed by the remote host.
> FILE: ..\src\main\activemq\network\SocketInputStream.cpp, LINE: 145
> FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 199
> FILE: ..\src\main\activemq\io\BufferedInputStream.cpp, LINE: 83
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 216
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 120
> FILE: ..\src\main\activemq\connector\stomp\StompCommandReader.cpp,
> LINE: 71
> FILE: ..\src\main\activemq\transport\IOTransport.cpp, LINE: 175
> {noformat}
> Again I see this message from both threads. Note the slightly different line
> numbers in SocketInputStream.cpp and the slighty different error message
> (this is on Windows XP SP2). In this case the failure of the socket is
> probably being detected in a slightly different place.
> If the socket failure happens in the second way, it seems that destructors of
> consumers (and possibly producers and sessions) don't properly catch the
> exception when being destroying, causing their destructors to throw an
> exception, which isn't what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
