You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Igor Katkov (JIRA)" <ji...@apache.org> on 2009/08/14 22:52:35 UTC
[jira] Created: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
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.
[jira] Commented: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Igor Katkov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53623#action_53623 ]
Igor Katkov commented on AMQNET-179:
------------------------------------
Yes, you may just throw it, that would break a lot of existing source code though. :-(
So what I did is the lesser evil - those who are interested in handling it will do
{code}
conFactory = new ConnectionFactory(URI);
connection = (Connection) conFactory.CreateConnection();
connection.ExceptionListener += ConnectionExceptionListener;
{code}
those who are not, just carry on
P.S.
FailoverTransport is completely broken in .NET client. I spent a day trying to make it work or even fix it. That's why I turned back to TcpTransport, implemented a hook and handled re-connection on upper application level. Not to mention that it does not support almost any configuration params from URL
How-to see that FailoverTransport is completely broken -
a.
1. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
2. Send a few messages
3. Restart the broker, while keep sending messages
4. Bingo! Your client hangs
b.
1. Stop your broker
2. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
3. Bingo! Connection will never be made
> 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: Timothy Bish
> 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.
[jira] Resolved: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQNET-179.
---------------------------------
Resolution: Fixed
Resolved in trunk. Removed the try/catch logic from the TcpTransport's oneway call and just propagate the exception up the stack. The Connection class ensures that all exception thrown from a failed send are NMSException's so a client that is using the TcpTransport only should add a try / catch around producer.Send calls to catch the error and shutdown or manually reconnect.
As for the Failover transport issues those have I hope all been resolved by other recent issue resolutions. Open a new issue if you have further trouble with Failover.
> 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
> Affects Versions: 1.1.0
> Reporter: Igor Katkov
> Assignee: Timothy Bish
> 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.
[jira] Assigned: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish reassigned AMQNET-179:
-----------------------------------
Assignee: Timothy Bish (was: Jim Gomes)
> 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: Timothy Bish
> 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.
[jira] Work started: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on AMQNET-179 started by Timothy Bish.
> 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
> Affects Versions: 1.1.0
> Reporter: Igor Katkov
> Assignee: Timothy Bish
> 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.
[jira] Issue Comment Edited: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Igor Katkov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53623#action_53623 ]
Igor Katkov edited comment on AMQNET-179 at 8/14/09 2:57 PM:
-------------------------------------------------------------
Yes, you may just throw it, that would break a lot of existing source code though. :-(
So what I did is the lesser evil - those who are interested in handling it will do
{code}
conFactory = new ConnectionFactory(URI);
connection = (Connection) conFactory.CreateConnection();
connection.ExceptionListener += ConnectionExceptionListener;
{code}
those who are not, just carry on
P.S.
FailoverTransport is completely broken in .NET client. I spent a day trying to make it work or even fix it. That's why I turned back to TcpTransport, implemented a hook and handled re-connection on upper application level. Not to mention that it does not support almost any configuration params from URL
How-to see that FailoverTransport is completely broken -
a.
1. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
2. Send a few messages
3. Restart the broker, while keep sending messages
4. Bingo! Your client hangs
b.
1. Stop your broker
2. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
3. Start the broker
4. Bingo! Connection will never be made
was (Author: igor):
Yes, you may just throw it, that would break a lot of existing source code though. :-(
So what I did is the lesser evil - those who are interested in handling it will do
{code}
conFactory = new ConnectionFactory(URI);
connection = (Connection) conFactory.CreateConnection();
connection.ExceptionListener += ConnectionExceptionListener;
{code}
those who are not, just carry on
P.S.
FailoverTransport is completely broken in .NET client. I spent a day trying to make it work or even fix it. That's why I turned back to TcpTransport, implemented a hook and handled re-connection on upper application level. Not to mention that it does not support almost any configuration params from URL
How-to see that FailoverTransport is completely broken -
a.
1. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
2. Send a few messages
3. Restart the broker, while keep sending messages
4. Bingo! Your client hangs
b.
1. Stop your broker
2. Connect c# to a broker via failovertransport to activemq:failover:tcp://localhost:61616
3. Bingo! Connection will never be made
> 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: Timothy Bish
> 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.
[jira] Commented: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53624#action_53624 ]
Timothy Bish commented on AMQNET-179:
-------------------------------------
I'm currently doing a lot of work in the transport area, so I will add this as something to fix.
> 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: Timothy Bish
> 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.
[jira] Commented: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AMQNET-179) TcpTransport.cs consumes
transport-related exceptions
Posted by "Igor Katkov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Katkov updated AMQNET-179:
-------------------------------
Attachment: patchfile.txt
Patch to fix.
> 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.