[
https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525138
]
Aman Nanner commented on GERONIMO-2880:
---------------------------------------
Hi Anish,
As per my last comment, I had discovered that the exception was being generated
because the connection was already closed by ActiveMQ due to an error that
occurred during the sending of the last message. This error message did not
appear in my log because my logging threshold was set above DEBUG, so I had
suggested that errors that occur during the sending of message should perhaps
be logged at a higher threshold level (such as WARN or ERROR).
Also, the source problem was this:
{{java.io.IOException: Cannot set AUTOCOMMIT ON when in an XA connection.}}
Does anybody know how to set AUTOCOMMIT to off for the JMS resource adapter?
> TransportDisposedIOException occurs when trying to close ActiveMQ queue
> -----------------------------------------------------------------------
>
> Key: GERONIMO-2880
> URL: https://issues.apache.org/jira/browse/GERONIMO-2880
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
> Affects Versions: 2.0.x
> Environment: Windows XP SP2
> Reporter: Aman Nanner
> Priority: Critical
> Fix For: 2.0.x, 2.1
>
>
> I have discovered some problems with queues while running unittest in our own
> J2EE app.
> After sending a message on a queue, when we try to call the close() method on
> the queue, we get the following exception:
> ----
> org.apache.activemq.transport.TransportDisposedIOException: Peer
> (vm://localhost#69) disposed.
> ----
> where the number after "localhost" is different every time.
> We do not experience this problem with topics. We are using ActiveMQ as part
> of an "embedded" configuration with Geronimo.
> I've done some debugging and the problem occurs at this line in the
> ActiveMQMessageProducer.close() method:
> ----
> this.session.asyncSendPacket(info.createRemoveCommand());
> ----
> The queue itself is disposed properly in the dispose() method that is called
> in the line before, but this sending of the asynchronous packet fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
