[
https://issues.apache.org/activemq/browse/AMQNET-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52129#action_52129
]
Jim Gomes commented on AMQNET-160:
----------------------------------
I'm OK with the backed out changes. If Michel is OK with this solution, then
let's close this issue. I can see arguments for handling the initial start-up
and connection with different client logic than handling a run-time disconnect.
My own application has a design requirement that it not proceed with start-up
if it is not connected to the messaging broker. This is a different scenario
than a run-time disconnect that happens to a long-running client connection.
When I issue the Connect() command, and I don't get an exception of some kind,
the assumption is that I am actively connected to a broker. However, with the
current solution, this is a bad assumption, but it is only bad if I happen to
be using the failover protocol. Using all other protocols, this is a correct
assumption. The problem here is that my client application does not, and
should not, know what protocol is being used, or even what broker I am
connecting to (ActiveMQ, vs. TIBCO). This is an externally configured setting.
I will need to study this further to determine how much of an issue this might
be for us.
Regarding Tim's comment above about the DNS resolution issues, I agree with
this scenario, which is why I disabled the IPHost caching code. Previously,
the IPHost entries were cached at first look-up for speed considerations. I
realized that with the failover protocol implemented, this could lead to never
recognizing that a host has come back online, perhaps with a new dynamic IP
address assigned to it. The code is still there, but just disabled. I think
that code should be looked at further, and perhaps only enabled if failover is
not being used.
> Connecting to non-existing host does not raise Exception when using failover
> protocol
> -------------------------------------------------------------------------------------
>
> Key: AMQNET-160
> URL: https://issues.apache.org/activemq/browse/AMQNET-160
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: Windows XP/Windows 2003 , .NET Framework 2.0 (Broker
> running Ubuntu 8.04 + ActiveMQ 5.2)
> Reporter: Michel Van Hoof
> Assignee: Jim Gomes
> Fix For: 1.1
>
>
> When using the failover protocol, there is no exception raised when trying to
> connect to non-existing host.
> Example:
> using System;
> using System.Collections.Generic;
> using System.Text;
> using Apache.NMS;
> using Apache.NMS.ActiveMQ;
> class ExceptionTest
> {
> private readonly IConnectionFactory oConnfact;
> private readonly IConnection oConn;
> private readonly ISession oSess;
> private readonly IMessageConsumer oConsumer;
> private string sConnectionUri = "failover:(tcp://unknownhost:61612)";
> // Using this connectionstring it does fail.
> //private string sConnectionUri = "tcp://unknownhost:61612";
> public ExceptionTest()
> {
> oConn.ExceptionListener += new ExceptionListener(OnException);
> this.oConnfact = new ConnectionFactory(sConnectionUri,
> "CLIENT.ID");
>
> oConn.ExceptionListener += new ExceptionListener(OnException);
> this.oConn = oConnfact.CreateConnection();
> oConn.RequestTimeout(new TimeSpan(0, 0, 2));
> // Code hangs here
> oConn.Start();
> //Rest does not really mather anymore since it hangs
>
> }
> void OnEx(Exception exception)
> {
> throw new Exception("The method or operation is not
> implemented.");
> }
> public void OnException(Exception ex)
> {
> Console.WriteLine("You made a BooBoo: {0} ", ex.ToString());
> }
> }
> If you change the connectionstring to "tcp://badhostname:xxxx" , the
> exception does occur.
> It also seems to ignore the RequestTimeout.
> This blocks the application thread indefinately since there is no way to
> recover from it (no exception thrown).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
