[
https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53622#action_53622
]
Timothy Bish commented on AMQNET-179:
-------------------------------------
You are correct, the TcpTransport's oneway call is obviously not handling that
exception correctly.
I don't think the patch is correct though, the oneway call should just throw
the exception and not mess with sending responses or exceptions to the
delegates. At the level of the oneway call you want the client's attempt to
send the command to raise an exception inline, not to some out of band handler,
the fact that the message requires a response is not really relevant at that
level as it never gets sent in the first place, other transports like the
Failover transport should handle exceptions from the TcpTransport's oneway
call, but if not using failover then you'd want this exception to bubble up to
the client's send call directly, not return quietly.
> TcpTransport.cs consumes transport-related exceptions
> -----------------------------------------------------
>
> Key: AMQNET-179
> URL: https://issues.apache.org/activemq/browse/AMQNET-179
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Affects Versions: 1.1.0
> Reporter: Igor Katkov
> Assignee: Jim Gomes
> Fix For: 1.2.0
>
> Attachments: patchfile.txt
>
>
> TcpTransport.cs consumes transport-related exceptions
> Therefore there is no way to handle broken connections in the client
> application.
> To reproduce:
> 1. Connect c# to a broker via tcp transport
> 2. Send a few messages
> 3. Restart the broker
> 4. Bingo! Client application thinks connection is up, while it's in fact
> broken for good.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
