You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Stefan Riesen (Created) (JIRA)" <ji...@apache.org> on 2012/01/20 17:37:39 UTC

[jira] [Created] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Unexpected behavior in FailoverTransport when hosts are unknown
---------------------------------------------------------------

                 Key: AMQ-3673
                 URL: https://issues.apache.org/jira/browse/AMQ-3673
             Project: ActiveMQ
          Issue Type: Bug
          Components: JMS client
    Affects Versions: 5.5.0
         Environment: MacOS X 10.5
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
            Reporter: Stefan Riesen
            Priority: Minor


There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.

failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:

failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):

private boolean contains(URI newURI) {

        boolean result = false;
        try {
        for (URI uri:uris) {
            if (newURI.getPort()==uri.getPort()) {
                InetAddress newAddr = InetAddress.getByName(newURI.getHost());
                InetAddress addr = InetAddress.getByName(uri.getHost());
                if (addr.equals(newAddr)) {
                    result = true;
                    break;
                }
            }
        }
        }catch(IOException e) {
            result = true;
            LOG.error("Failed to verify URI " + newURI + " already known: " + e);
        }
        return result;
    }

That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).

In above mentioned case in the second call to this method this line fails with a UnknownHostException: 

InetAddress addr = InetAddress.getByName(uri.getHost());

and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.

I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Timothy Bish (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191196#comment-13191196 ] 

Timothy Bish commented on AMQ-3673:
-----------------------------------

You need to ensure that you tick the grant license to apache when attaching test cases and patches otherwise we can't use them.  
                
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: FailoverNoHostException.java, patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> {noformat}
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> {noformat}
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> {noformat}
> InetAddress addr = InetAddress.getByName(uri.getHost());
> {noformat}
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Stefan Riesen (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Riesen updated AMQ-3673:
-------------------------------

    Attachment: FailoverNoHostException.java
    
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: FailoverNoHostException.java, patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> InetAddress addr = InetAddress.getByName(uri.getHost());
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Timothy Bish (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish resolved AMQ-3673.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 5.6.0
         Assignee: Timothy Bish

Fix applied in trunk with tests.
                
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Assignee: Timothy Bish
>            Priority: Minor
>             Fix For: 5.6.0
>
>         Attachments: FailoverNoHostException.java, patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> {noformat}
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> {noformat}
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> {noformat}
> InetAddress addr = InetAddress.getByName(uri.getHost());
> {noformat}
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Timothy Bish (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish updated AMQ-3673:
------------------------------

    Description: 
There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.

failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:

failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):

{noformat}

private boolean contains(URI newURI) {

        boolean result = false;
        try {
        for (URI uri:uris) {
            if (newURI.getPort()==uri.getPort()) {
                InetAddress newAddr = InetAddress.getByName(newURI.getHost());
                InetAddress addr = InetAddress.getByName(uri.getHost());
                if (addr.equals(newAddr)) {
                    result = true;
                    break;
                }
            }
        }
        }catch(IOException e) {
            result = true;
            LOG.error("Failed to verify URI " + newURI + " already known: " + e);
        }
        return result;
    }

{noformat}

That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).

In above mentioned case in the second call to this method this line fails with a UnknownHostException: 

{noformat}
InetAddress addr = InetAddress.getByName(uri.getHost());
{noformat}

and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.

I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

  was:
There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.

failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:

failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false

The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):

private boolean contains(URI newURI) {

        boolean result = false;
        try {
        for (URI uri:uris) {
            if (newURI.getPort()==uri.getPort()) {
                InetAddress newAddr = InetAddress.getByName(newURI.getHost());
                InetAddress addr = InetAddress.getByName(uri.getHost());
                if (addr.equals(newAddr)) {
                    result = true;
                    break;
                }
            }
        }
        }catch(IOException e) {
            result = true;
            LOG.error("Failed to verify URI " + newURI + " already known: " + e);
        }
        return result;
    }

That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).

In above mentioned case in the second call to this method this line fails with a UnknownHostException: 

InetAddress addr = InetAddress.getByName(uri.getHost());

and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.

I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

    
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: FailoverNoHostException.java, patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> {noformat}
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> {noformat}
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> {noformat}
> InetAddress addr = InetAddress.getByName(uri.getHost());
> {noformat}
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Stefan Riesen (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190347#comment-13190347 ] 

Stefan Riesen commented on AMQ-3673:
------------------------------------

Added testcase
                
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: FailoverNoHostException.java, patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> InetAddress addr = InetAddress.getByName(uri.getHost());
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Timothy Bish (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189884#comment-13189884 ] 

Timothy Bish commented on AMQ-3673:
-----------------------------------

We need a test case to validate the behavior.  
                
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> InetAddress addr = InetAddress.getByName(uri.getHost());
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (AMQ-3673) Unexpected behavior in FailoverTransport when hosts are unknown

Posted by "Stefan Riesen (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AMQ-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Riesen updated AMQ-3673:
-------------------------------

    Attachment: patch.diff

Patch that changes Log entry and return value
                
> Unexpected behavior in FailoverTransport when hosts are unknown
> ---------------------------------------------------------------
>
>                 Key: AMQ-3673
>                 URL: https://issues.apache.org/jira/browse/AMQ-3673
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>         Environment: MacOS X 10.5
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
>            Reporter: Stefan Riesen
>            Priority: Minor
>         Attachments: patch.diff
>
>
> There's an unexpected behavior when a failover url is specified where the first host does not exist, e.g.
> failover:(tcp://nonexistinghost.mydomain.com:61616,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover code will never switch to the tcp://existinghost.mydomain.com:61616 while when using this url:
> failover:(tcp://nonexistinghost.mydomain.com:61617,tcp://existinghost.mydomain.com:61616)?randomize=false
> The failover works flawlessly. I tracket the problem down to the method org.apache.activemq.transport.failover.FailoverTransport.contains(URI):
> private boolean contains(URI newURI) {
>         boolean result = false;
>         try {
>         for (URI uri:uris) {
>             if (newURI.getPort()==uri.getPort()) {
>                 InetAddress newAddr = InetAddress.getByName(newURI.getHost());
>                 InetAddress addr = InetAddress.getByName(uri.getHost());
>                 if (addr.equals(newAddr)) {
>                     result = true;
>                     break;
>                 }
>             }
>         }
>         }catch(IOException e) {
>             result = true;
>             LOG.error("Failed to verify URI " + newURI + " already known: " + e);
>         }
>         return result;
>     }
> That only resolves hostnames if the ports are not equal (this is why the different port behavior comes from).
> In above mentioned case in the second call to this method this line fails with a UnknownHostException: 
> InetAddress addr = InetAddress.getByName(uri.getHost());
> and the result of contains() is set to true because of the catch block, therefore the second URL isn't added to the list of urls.
> I suggest to change the catch block to return false. In case of an IOException during the check it's hard to say whether the URIs are the same or not, but it's more likely that they're not the same as in this case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira