[jira] Created: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
--------------------------------------------------------------------------------------------------------------

                 Key: AMQ-2771
                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
             Project: ActiveMQ
          Issue Type: Wish
    Affects Versions: 5.3.2, 5.3.1, 5.3.0
            Reporter: Przemek Bruski


TcpTransport.java contains the following code:

{code}
    protected String resolveHostName(String host) throws UnknownHostException {
        String localName = InetAddress.getLocalHost().getHostName();
        if (localName != null && isUseLocalHost()) {
            if (localName.equals(host)) {
                return "localhost";
            }
        }
        return host;
    }
{code}

TcpTransportServer.java contains the following code:

{code}
        InetAddress addr = InetAddress.getByName(host);

        try {

            this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
{code}

/etc/hosts looks like this:

127.0.0.1       localhost.localdomain   localhost
someip       myhostname.mydomain myhostname

Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).

I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).

This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.

Questions:
1. Can the default behaviour be changed to one that would work on majority of systems?
2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
3. The debug messages are misleading and probably should be changed:

[ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
[ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
[ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused

In fact, it was the connection to localhost:54663 that was refused.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org

     [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Przemek Bruski updated AMQ-2771:
--------------------------------

    Description:
TcpTransport.java contains the following code:

{code}
    protected String resolveHostName(String host) throws UnknownHostException {
        String localName = InetAddress.getLocalHost().getHostName();
        if (localName != null && isUseLocalHost()) {
            if (localName.equals(host)) {
                return "localhost";
            }
        }
        return host;
    }
{code}

TcpTransportServer.java contains the following code:

{code}
        InetAddress addr = InetAddress.getByName(host);

        try {

            this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
{code}

/etc/hosts looks like this:

{code}
127.0.0.1       localhost.localdomain   localhost
someip       myhostname.mydomain myhostname
{code}

Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).

I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).

This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.

Questions:
1. Can the default behaviour be changed to one that would work on majority of systems?
2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
3. The debug messages are misleading and probably should be changed:

[ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
[ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
[ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused

In fact, it was the connection to localhost:54663 that was refused.


  was:
TcpTransport.java contains the following code:

{code}
    protected String resolveHostName(String host) throws UnknownHostException {
        String localName = InetAddress.getLocalHost().getHostName();
        if (localName != null && isUseLocalHost()) {
            if (localName.equals(host)) {
                return "localhost";
            }
        }
        return host;
    }
{code}

TcpTransportServer.java contains the following code:

{code}
        InetAddress addr = InetAddress.getByName(host);

        try {

            this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
{code}

/etc/hosts looks like this:

127.0.0.1       localhost.localdomain   localhost
someip       myhostname.mydomain myhostname

Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).

I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).

This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.

Questions:
1. Can the default behaviour be changed to one that would work on majority of systems?
2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
3. The debug messages are misleading and probably should be changed:

[ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
[ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
[ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused

In fact, it was the connection to localhost:54663 that was refused.



> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Lindquist updated AMQ-2771:
--------------------------------

    Attachment: BrokerServiceResolveHostTest.java

The attached file "BrokerServiceResolveHostTest.java" is a comprehensive JUnit TestCase that will show this issue.

As the submitter of the issue mentioned, the problem is that the resolveHostName method in TcpTransport is incorrectly changing the machine name (which resolves to a true IP address) into 'localhost' (which resolves to 127.0.0.1).

In the attached test case, I've attempted to get EVERY name and address that is local to the machine, and test creating a broker and connecting to that broker with that name form.

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60023#action_60023 ]

Dave Lindquist commented on AMQ-2771:
-------------------------------------

The comments in the code seem to indicate that this is done to handle certain O/S (Mac) that do not let you connect to the local name?

I'm thinking that the code should look more like:

{code:title=TcpTransport.java}
...
protected String resolveHostName(String host) throws UnknownHostException {
        String localName = InetAddress.getLocalHost().getHostName();
        if (localName != null && isUseLocalHost()) {
            if (localName.equals(host) && InetAddress.getByName(host).getHostAddress().equals(InetAddress.getByName("localhost").getHostAddress())) {
                return "localhost";
            }
        }
        return host;
    }
...
{code}

The added portion is:
{code}... && InetAddress.getByName(host).getHostAddress().equals(InetAddress.getByName("localhost").getHostAddress()) ...{code}
which will make sure that changing the host to 'localhost' does not change the RESOLUTION of the name.  However, I'm not sure if this will then 'break' the MacOS case...

To me, the MacOS case sounds like an operating system bug?


Finally, there is an option on TcpTransport called 'setUseLocalHost' -- unfortunately, this does not seem to be accessible anywhere?

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60025#action_60025 ]

Gary Tully commented on AMQ-2771:
---------------------------------

on the setUseLocalHost, that can be set from the uri via a parameter, it will be set via introspection/reflection {code}tcp://hostname:54663?useLocalHost=true{code}

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60996#action_60996 ]

Eric commented on AMQ-2771:
---------------------------

An other side effect of the change, concerns multicast discovery.
 
- 2 distinct brokers are on the same server with MulticastDiscovery, a third one is on another server
- the first has a transport connector with "address:port?useLocalHost=false" (binding on the address;port is a security choice) + Multicast Discovery,
- the second and the third have the corresponding network connector,

the second broker doesn't succeed in connecting to the first one. The third one is OK.

Example :
<transportConnector name="TestDeCharge-DEFAULT-IN"
uri="tcp://td0sib01s.priv.atos.fr:61616?useLocalHost=false"
discoveryUri="multicast://default?group=TestDeCharge-DEFAULT"/>

In 5.3.0, the corresponding multicast frame is

[root@td0sib01s ~]# tcpdump -s 200 -c 4 src host td0sib01s and ip multicast -X
09:59:02.870809 IP td0sib01s.priv.atos.fr.6155 > 239.255.2.3.6155: UDP, length 102
0x0000: 4500 0082 0000 4000 0111 959b 0a18 e7b5 E.....@.........
0x0010: efff 0203 180b 180b 006e e44f 5465 7374 .........n.OTest
0x0020: 4465 4368 6172 6765 2d44 4546 4155 4c54 DeCharge-DEFAULT
0x0030: 2e41 6374 6976 654d 512d 342e 616c 6976 .ActiveMQ-4.aliv
0x0040: 652e 256c 6f63 616c 686f 7374 2574 6370 e.%localhost%tcp
0x0050: 3a2f 2f74 6430 7369 6230 3173 2e70 7269 ://td0sib01s.pri
0x0060: 762e 6174 6f73 2e66 723a 3631 3631 363f v.atos.fr:61616?
0x0070: 7573 654c 6f63 616c 486f 7374 3d66 616c useLocalHost=fal
0x0080: 7365 se


In 5.3.2, the corresponding multicast frame is


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 200 bytes
09:51:30.818735 IP td0sib01s.priv.atos.fr.6155 > 239.255.2.3.6155: UDP, length 83
0x0000: 4500 006f 0000 4000 0111 95ae 0a18 e7b5 E..o..@.........
0x0010: efff 0203 180b 180b 005b e43c 5465 7374 .........[.<Test
0x0020: 4465 4368 6172 6765 2d44 4546 4155 4c54 DeCharge-DEFAULT
0x0030: 2e41 6374 6976 654d 512d 342e 616c 6976 .ActiveMQ-4.aliv
0x0040: 652e 256c 6f63 616c 686f 7374 2574 6370 e.%localhost%tcp
0x0050: 3a2f 2f74 6430 7369 6230 3173 2e70 7269 ://td0sib01s.pri
0x0060: 762e 6174 6f73 2e66 723a 3631 3631 36 v.atos.fr:61616


In 5.3.2 Multicast frame doesn't contain the option "?useLocalHost=false", so, with this resolveHostName the network connector tries to use "localhost" to connect.

Eric-AWL

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>             Fix For: 5.4.1
>
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003 ]

Gary Tully commented on AMQ-2771:
---------------------------------

it does look like the useLocalHost option should default to false as it is an override option that results in a hard coded answer.

Eric, for the multicast case, apply the parameters to the multicast url used by the networkconnector, that fact that it is no longer propagated in the discovery multicast frame requires the option to be explicitly set by the user of that information.

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>             Fix For: 5.4.1
>
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

Eric-AWL
Euuuuh, I don't know if I understand what you explain me :

      <networkConnector name="TestDeCharge-DEFAULT-OUT"
                        uri="multicast://default?group=TestDeCharge-DEFAULT"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"/>

=>
       <networkConnector name="TestDeCharge-DEFAULT-OUT"
                        uri="multicast://default?group=TestDeCharge-DEFAULT"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"
                        <b>useLocalHost="false"/>

I don't see this new option of networkConnector in the documentation web site.

???

JIRA jira@apache.org wrote
    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003 ]

Gary Tully commented on AMQ-2771:
---------------------------------

it does look like the useLocalHost option should default to false as it is an override option that results in a hard coded answer.

Eric, for the multicast case, apply the parameters to the multicast url used by the networkconnector, that fact that it is no longer propagated in the discovery multicast frame requires the option to be explicitly set by the user of that information.

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>             Fix For: 5.4.1
>
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

gtully
append the transport options to the uri:

multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false

the discovery transport will pull off the parameters it knows about
(eg group) and leave the rest for the discovered transport.

On 30 July 2010 15:25, Eric-AWL <[hidden email]> wrote:

>
> Euuuuh, I don't know if I understand what you explain me :
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>                        uri="multicast://default?group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> =>
>       <networkConnector name="TestDeCharge-DEFAULT-OUT"
>                        uri="multicast://default?group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"
>                        useLocalHost="false"/>
>
> I don't see this new option of networkConnector in the documentation web
> site.
>
> ???
>
>
> JIRA [hidden email] wrote:
>>
>>
>>     [
>> https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003
>> ]
>>
>> Gary Tully commented on AMQ-2771:
>> ---------------------------------
>>
>> it does look like the useLocalHost option should default to false as it is
>> an override option that results in a hard coded answer.
>>
>> Eric, for the multicast case, apply the parameters to the multicast url
>> used by the networkconnector, that fact that it is no longer propagated in
>> the discovery multicast frame requires the option to be explicitly set by
>> the user of that information.
>>
>>> Side effect from AMQ-2094, server listens on host name address, client
>>> connects to localhost with the same URI
>>> --------------------------------------------------------------------------------------------------------------
>>>
>>>                 Key: AMQ-2771
>>>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>>>             Project: ActiveMQ
>>>          Issue Type: Wish
>>>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>>>            Reporter: Przemek Bruski
>>>             Fix For: 5.4.1
>>>
>>>         Attachments: BrokerServiceResolveHostTest.java
>>>
>>>
>>> TcpTransport.java contains the following code:
>>> {code}
>>>     protected String resolveHostName(String host) throws
>>> UnknownHostException {
>>>         String localName = InetAddress.getLocalHost().getHostName();
>>>         if (localName != null && isUseLocalHost()) {
>>>             if (localName.equals(host)) {
>>>                 return "localhost";
>>>             }
>>>         }
>>>         return host;
>>>     }
>>> {code}
>>> TcpTransportServer.java contains the following code:
>>> {code}
>>>         InetAddress addr = InetAddress.getByName(host);
>>>         try {
>>>             this.serverSocket =
>>> serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
>>> {code}
>>> /etc/hosts looks like this:
>>> {code}
>>> 127.0.0.1       localhost.localdomain   localhost
>>> someip       myhostname.mydomain myhostname
>>> {code}
>>> Now, if I start server with uri: myhostname.mydomain, the server will
>>> listen on someip but the client started on the same host with the same
>>> uri will try connect to localhost (and fail).
>>> I know that useLocalHost can be used to avoid it, but silently connecting
>>> to localhost is counterintuitive and does not sound like a valid default
>>> behaviour (according to documentation, using localhost instead of the
>>> host name is a workaround, the workaround is now effectively default
>>> behaviour and breaks valid setups that used to work with 5.2).
>>> This worked fine on 5.2, since the server bound to all interfaces - but
>>> fixing this was obviously the right thing to do.
>>> Questions:
>>> 1. Can the default behaviour be changed to one that would work on
>>> majority of systems?
>>> 2. Is the workaround really needed? Maybe it's the local network settings
>>> that should be corrected?
>>> 3. The debug messages are misleading and probably should be changed:
>>> [ActiveMQ Task] [FailoverTransport:604] urlList
>>> connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
>>> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
>>> [ActiveMQ Task] [FailoverTransport:764] Connect fail to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason:
>>> java.net.ConnectException: Connection refused
>>> In fact, it was the connection to localhost:54663 that was refused.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29306610.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



--
http://blog.garytully.com

Open Source Integration
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

Eric-AWL
Hi Gary

Ok I found the option in the networkConnection documentation, but, in 5.3.2

      <networkConnector name="TestDeCharge-DEFAULT-OUT"
                        uri="multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"/>

I get

2010/07/30;17:05:16:513;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 34 in XML document from class path resource [activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity "useLocalHost" must end with the ';' delimiter.

if I swap group and useLocalHost :

<networkConnector name="TestDeCharge-DEFAULT-OUT"
                        uri="multicast://default?useLocalHost=false&group=TestDeCharge-DEFAULT"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"/>


2010/07/30;17:15:09:279;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 34 in XML document from class path resource [activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The reference to entity "group" must end with the ';' delimiter.


If I use "&*amp;" as I found some answers for old forums questions

      <networkConnector name="TestDeCharge-DEFAULT-OUT"
                        uri="multicast://default?group=TestDeCharge-DEFAULT&*amp;useLocalHost=false"
                        networkTTL="1"
                        conduitSubscriptions="false"
                        dynamicOnly="true"
                        duplex="false"/>

I get

2010/07/30;17:18:45:037;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 34 in XML document from class path resource [activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException: The entity name must immediately follow the '&' in the entity reference.

It seems to be a kind of AMQ-2598 error that referenced AMQ-1099

Sorry for all these small problems.

Eric-AWL

Gary Tully wrote
append the transport options to the uri:

multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false

the discovery transport will pull off the parameters it knows about
(eg group) and leave the rest for the discovered transport.

On 30 July 2010 15:25, Eric-AWL <eric.vincent@atosorigin.com> wrote:
>
> Euuuuh, I don't know if I understand what you explain me :
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>                        uri="multicast://default?group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> =>
>       <networkConnector name="TestDeCharge-DEFAULT-OUT"
>                        uri="multicast://default?group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"
>                        useLocalHost="false"/>
>
> I don't see this new option of networkConnector in the documentation web
> site.
>
> ???
>
>
> JIRA jira@apache.org wrote:
>>
>>
>>     [
>> https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003
>> ]
>>
>> Gary Tully commented on AMQ-2771:
>> ---------------------------------
>>
>> it does look like the useLocalHost option should default to false as it is
>> an override option that results in a hard coded answer.
>>
>> Eric, for the multicast case, apply the parameters to the multicast url
>> used by the networkconnector, that fact that it is no longer propagated in
>> the discovery multicast frame requires the option to be explicitly set by
>> the user of that information.
>>
>>> Side effect from AMQ-2094, server listens on host name address, client
>>> connects to localhost with the same URI
>>> --------------------------------------------------------------------------------------------------------------
>>>
>>>                 Key: AMQ-2771
>>>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>>>             Project: ActiveMQ
>>>          Issue Type: Wish
>>>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>>>            Reporter: Przemek Bruski
>>>             Fix For: 5.4.1
>>>
>>>         Attachments: BrokerServiceResolveHostTest.java
>>>
>>>
>>> TcpTransport.java contains the following code:
>>> {code}
>>>     protected String resolveHostName(String host) throws
>>> UnknownHostException {
>>>         String localName = InetAddress.getLocalHost().getHostName();
>>>         if (localName != null && isUseLocalHost()) {
>>>             if (localName.equals(host)) {
>>>                 return "localhost";
>>>             }
>>>         }
>>>         return host;
>>>     }
>>> {code}
>>> TcpTransportServer.java contains the following code:
>>> {code}
>>>         InetAddress addr = InetAddress.getByName(host);
>>>         try {
>>>             this.serverSocket =
>>> serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
>>> {code}
>>> /etc/hosts looks like this:
>>> {code}
>>> 127.0.0.1       localhost.localdomain   localhost
>>> someip       myhostname.mydomain myhostname
>>> {code}
>>> Now, if I start server with uri: myhostname.mydomain, the server will
>>> listen on someip but the client started on the same host with the same
>>> uri will try connect to localhost (and fail).
>>> I know that useLocalHost can be used to avoid it, but silently connecting
>>> to localhost is counterintuitive and does not sound like a valid default
>>> behaviour (according to documentation, using localhost instead of the
>>> host name is a workaround, the workaround is now effectively default
>>> behaviour and breaks valid setups that used to work with 5.2).
>>> This worked fine on 5.2, since the server bound to all interfaces - but
>>> fixing this was obviously the right thing to do.
>>> Questions:
>>> 1. Can the default behaviour be changed to one that would work on
>>> majority of systems?
>>> 2. Is the workaround really needed? Maybe it's the local network settings
>>> that should be corrected?
>>> 3. The debug messages are misleading and probably should be changed:
>>> [ActiveMQ Task] [FailoverTransport:604] urlList
>>> connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
>>> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
>>> [ActiveMQ Task] [FailoverTransport:764] Connect fail to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason:
>>> java.net.ConnectException: Connection refused
>>> In fact, it was the connection to localhost:54663 that was refused.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29306610.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



--
http://blog.garytully.com

Open Source Integration
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

gtully
that is xml syntax validation. u need to use &amp; for &

see: http://www.stylusstudio.com/w3c/xml11/sec-references.htm



On 30 July 2010 16:28, Eric-AWL <[hidden email]> wrote:

>
> Hi Gary
>
> Ok I found the option in the networkConnection documentation, but, in 5.3.2
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> I get
>
> 2010/07/30;17:05:16:513;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The reference to entity
> "useLocalHost" must end with the ';' delimiter.
>
> if I swap group and useLocalHost :
>
> <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?useLocalHost=false&group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
>
> 2010/07/30;17:15:09:279;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The reference to entity
> "group" must end with the ';' delimiter.
>
>
> If I use "&*amp;" as I found some answers for old forums questions
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?group=TestDeCharge-DEFAULT&*amp;useLocalHost=false"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> I get
>
> 2010/07/30;17:18:45:037;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The entity name must
> immediately follow the '&' in the entity reference.
>
> It seems to be a kind of AMQ-2598 error that referenced AMQ-1099
>
> Sorry for all these small problems.
>
> Eric-AWL
>
>
> Gary Tully wrote:
>>
>> append the transport options to the uri:
>>
>> multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false
>>
>> the discovery transport will pull off the parameters it knows about
>> (eg group) and leave the rest for the discovered transport.
>>
>> On 30 July 2010 15:25, Eric-AWL <[hidden email]> wrote:
>>>
>>> Euuuuh, I don't know if I understand what you explain me :
>>>
>>>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>>>
>>>  uri="multicast://default?group=TestDeCharge-DEFAULT"
>>>                        networkTTL="1"
>>>                        conduitSubscriptions="false"
>>>                        dynamicOnly="true"
>>>                        duplex="false"/>
>>>
>>> =>
>>>       <networkConnector name="TestDeCharge-DEFAULT-OUT"
>>>
>>>  uri="multicast://default?group=TestDeCharge-DEFAULT"
>>>                        networkTTL="1"
>>>                        conduitSubscriptions="false"
>>>                        dynamicOnly="true"
>>>                        duplex="false"
>>>                        useLocalHost="false"/>
>>>
>>> I don't see this new option of networkConnector in the documentation web
>>> site.
>>>
>>> ???
>>>
>>>
>>> JIRA [hidden email] wrote:
>>>>
>>>>
>>>>     [
>>>> https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003
>>>> ]
>>>>
>>>> Gary Tully commented on AMQ-2771:
>>>> ---------------------------------
>>>>
>>>> it does look like the useLocalHost option should default to false as it
>>>> is
>>>> an override option that results in a hard coded answer.
>>>>
>>>> Eric, for the multicast case, apply the parameters to the multicast url
>>>> used by the networkconnector, that fact that it is no longer propagated
>>>> in
>>>> the discovery multicast frame requires the option to be explicitly set
>>>> by
>>>> the user of that information.
>>>>
>>>>> Side effect from AMQ-2094, server listens on host name address, client
>>>>> connects to localhost with the same URI
>>>>> --------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>                 Key: AMQ-2771
>>>>>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>>>>>             Project: ActiveMQ
>>>>>          Issue Type: Wish
>>>>>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>>>>>            Reporter: Przemek Bruski
>>>>>             Fix For: 5.4.1
>>>>>
>>>>>         Attachments: BrokerServiceResolveHostTest.java
>>>>>
>>>>>
>>>>> TcpTransport.java contains the following code:
>>>>> {code}
>>>>>     protected String resolveHostName(String host) throws
>>>>> UnknownHostException {
>>>>>         String localName = InetAddress.getLocalHost().getHostName();
>>>>>         if (localName != null && isUseLocalHost()) {
>>>>>             if (localName.equals(host)) {
>>>>>                 return "localhost";
>>>>>             }
>>>>>         }
>>>>>         return host;
>>>>>     }
>>>>> {code}
>>>>> TcpTransportServer.java contains the following code:
>>>>> {code}
>>>>>         InetAddress addr = InetAddress.getByName(host);
>>>>>         try {
>>>>>             this.serverSocket =
>>>>> serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
>>>>> {code}
>>>>> /etc/hosts looks like this:
>>>>> {code}
>>>>> 127.0.0.1       localhost.localdomain   localhost
>>>>> someip       myhostname.mydomain myhostname
>>>>> {code}
>>>>> Now, if I start server with uri: myhostname.mydomain, the server will
>>>>> listen on someip but the client started on the same host with the same
>>>>> uri will try connect to localhost (and fail).
>>>>> I know that useLocalHost can be used to avoid it, but silently
>>>>> connecting
>>>>> to localhost is counterintuitive and does not sound like a valid
>>>>> default
>>>>> behaviour (according to documentation, using localhost instead of the
>>>>> host name is a workaround, the workaround is now effectively default
>>>>> behaviour and breaks valid setups that used to work with 5.2).
>>>>> This worked fine on 5.2, since the server bound to all interfaces - but
>>>>> fixing this was obviously the right thing to do.
>>>>> Questions:
>>>>> 1. Can the default behaviour be changed to one that would work on
>>>>> majority of systems?
>>>>> 2. Is the workaround really needed? Maybe it's the local network
>>>>> settings
>>>>> that should be corrected?
>>>>> 3. The debug messages are misleading and probably should be changed:
>>>>> [ActiveMQ Task] [FailoverTransport:604] urlList
>>>>> connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
>>>>> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to:
>>>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
>>>>> [ActiveMQ Task] [FailoverTransport:764] Connect fail to:
>>>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason:
>>>>> java.net.ConnectException: Connection refused
>>>>> In fact, it was the connection to localhost:54663 that was refused.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29306610.html
>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> http://blog.garytully.com
>>
>> Open Source Integration
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29307245.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



--
http://blog.garytully.com

Open Source Integration
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

Eric-AWL
Hi Gary


Ok
&               on the tranport connector  for the tcp URL
& a m p ;    on the corresponding network connector for the multicast URL

works.

It's not natural.

As far as I'm concerned, I would find more logical that "false" was the default value.

Thank you.
Eric-AWL

Gary Tully wrote
that is xml syntax validation. u need to use & for &

see: http://www.stylusstudio.com/w3c/xml11/sec-references.htm



On 30 July 2010 16:28, Eric-AWL <eric.vincent@atosorigin.com> wrote:
>
> Hi Gary
>
> Ok I found the option in the networkConnection documentation, but, in 5.3.2
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> I get
>
> 2010/07/30;17:05:16:513;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The reference to entity
> "useLocalHost" must end with the ';' delimiter.
>
> if I swap group and useLocalHost :
>
> <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?useLocalHost=false&group=TestDeCharge-DEFAULT"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
>
> 2010/07/30;17:15:09:279;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The reference to entity
> "group" must end with the ';' delimiter.
>
>
> If I use "&*amp;" as I found some answers for old forums questions
>
>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>
> uri="multicast://default?group=TestDeCharge-DEFAULT&*amp;useLocalHost=false"
>                        networkTTL="1"
>                        conduitSubscriptions="false"
>                        dynamicOnly="true"
>                        duplex="false"/>
>
> I get
>
> 2010/07/30;17:18:45:037;ERR;CInstance;Serveur(td0sib01s.priv.atos.fr);NA;NA;BUSACT-0000;(Exception)
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 34 in XML document from class path resource [activemq.xml] is invalid;
> nested exception is org.xml.sax.SAXParseException: The entity name must
> immediately follow the '&' in the entity reference.
>
> It seems to be a kind of AMQ-2598 error that referenced AMQ-1099
>
> Sorry for all these small problems.
>
> Eric-AWL
>
>
> Gary Tully wrote:
>>
>> append the transport options to the uri:
>>
>> multicast://default?group=TestDeCharge-DEFAULT&useLocalHost=false
>>
>> the discovery transport will pull off the parameters it knows about
>> (eg group) and leave the rest for the discovered transport.
>>
>> On 30 July 2010 15:25, Eric-AWL <eric.vincent@atosorigin.com> wrote:
>>>
>>> Euuuuh, I don't know if I understand what you explain me :
>>>
>>>      <networkConnector name="TestDeCharge-DEFAULT-OUT"
>>>
>>>  uri="multicast://default?group=TestDeCharge-DEFAULT"
>>>                        networkTTL="1"
>>>                        conduitSubscriptions="false"
>>>                        dynamicOnly="true"
>>>                        duplex="false"/>
>>>
>>> =>
>>>       <networkConnector name="TestDeCharge-DEFAULT-OUT"
>>>
>>>  uri="multicast://default?group=TestDeCharge-DEFAULT"
>>>                        networkTTL="1"
>>>                        conduitSubscriptions="false"
>>>                        dynamicOnly="true"
>>>                        duplex="false"
>>>                        useLocalHost="false"/>
>>>
>>> I don't see this new option of networkConnector in the documentation web
>>> site.
>>>
>>> ???
>>>
>>>
>>> JIRA jira@apache.org wrote:
>>>>
>>>>
>>>>     [
>>>> https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003
>>>> ]
>>>>
>>>> Gary Tully commented on AMQ-2771:
>>>> ---------------------------------
>>>>
>>>> it does look like the useLocalHost option should default to false as it
>>>> is
>>>> an override option that results in a hard coded answer.
>>>>
>>>> Eric, for the multicast case, apply the parameters to the multicast url
>>>> used by the networkconnector, that fact that it is no longer propagated
>>>> in
>>>> the discovery multicast frame requires the option to be explicitly set
>>>> by
>>>> the user of that information.
>>>>
>>>>> Side effect from AMQ-2094, server listens on host name address, client
>>>>> connects to localhost with the same URI
>>>>> --------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>                 Key: AMQ-2771
>>>>>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>>>>>             Project: ActiveMQ
>>>>>          Issue Type: Wish
>>>>>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>>>>>            Reporter: Przemek Bruski
>>>>>             Fix For: 5.4.1
>>>>>
>>>>>         Attachments: BrokerServiceResolveHostTest.java
>>>>>
>>>>>
>>>>> TcpTransport.java contains the following code:
>>>>> {code}
>>>>>     protected String resolveHostName(String host) throws
>>>>> UnknownHostException {
>>>>>         String localName = InetAddress.getLocalHost().getHostName();
>>>>>         if (localName != null && isUseLocalHost()) {
>>>>>             if (localName.equals(host)) {
>>>>>                 return "localhost";
>>>>>             }
>>>>>         }
>>>>>         return host;
>>>>>     }
>>>>> {code}
>>>>> TcpTransportServer.java contains the following code:
>>>>> {code}
>>>>>         InetAddress addr = InetAddress.getByName(host);
>>>>>         try {
>>>>>             this.serverSocket =
>>>>> serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
>>>>> {code}
>>>>> /etc/hosts looks like this:
>>>>> {code}
>>>>> 127.0.0.1       localhost.localdomain   localhost
>>>>> someip       myhostname.mydomain myhostname
>>>>> {code}
>>>>> Now, if I start server with uri: myhostname.mydomain, the server will
>>>>> listen on someip but the client started on the same host with the same
>>>>> uri will try connect to localhost (and fail).
>>>>> I know that useLocalHost can be used to avoid it, but silently
>>>>> connecting
>>>>> to localhost is counterintuitive and does not sound like a valid
>>>>> default
>>>>> behaviour (according to documentation, using localhost instead of the
>>>>> host name is a workaround, the workaround is now effectively default
>>>>> behaviour and breaks valid setups that used to work with 5.2).
>>>>> This worked fine on 5.2, since the server bound to all interfaces - but
>>>>> fixing this was obviously the right thing to do.
>>>>> Questions:
>>>>> 1. Can the default behaviour be changed to one that would work on
>>>>> majority of systems?
>>>>> 2. Is the workaround really needed? Maybe it's the local network
>>>>> settings
>>>>> that should be corrected?
>>>>> 3. The debug messages are misleading and probably should be changed:
>>>>> [ActiveMQ Task] [FailoverTransport:604] urlList
>>>>> connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
>>>>> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to:
>>>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
>>>>> [ActiveMQ Task] [FailoverTransport:764] Connect fail to:
>>>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason:
>>>>> java.net.ConnectException: Connection refused
>>>>> In fact, it was the connection to localhost:54663 that was refused.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29306610.html
>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> http://blog.garytully.com
>>
>> Open Source Integration
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://old.nabble.com/-jira--Created%3A-%28AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-address%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29307245.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



--
http://blog.garytully.com

Open Source Integration
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61003#action_61003 ]

Gary Tully edited comment on AMQ-2771 at 8/6/10 9:46 AM:
---------------------------------------------------------

it does look like the useLocalHost option should default to false as it is an override option that results in a hard coded answer.

Eric, for the multicast case, apply the parameters to the multicast url used by the networkconnector, that fact that it is no longer propagated in the discovery multicast frame requires the option to be explicitly set by the user of that information.


append the transport options to the uri:

multicast://default?group=TestDeCharge-DEFAULT&amp;useLocalHost=false

the discovery transport will pull off the parameters it knows about
(eg group) and leave the rest for the discovered transport.

      was (Author: gtully):
    it does look like the useLocalHost option should default to false as it is an override option that results in a hard coded answer.

Eric, for the multicast case, apply the parameters to the multicast url used by the networkconnector, that fact that it is no longer propagated in the discovery multicast frame requires the option to be explicitly set by the user of that information.
 

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>             Fix For: 5.4.1
>
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/activemq/browse/AMQ-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully resolved AMQ-2771.
-----------------------------

         Assignee: Gary Tully
    Fix Version/s: 5.4.0
                       (was: 5.4.1)
       Resolution: Fixed

default changed in r982962

> Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2771
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2771
>             Project: ActiveMQ
>          Issue Type: Wish
>    Affects Versions: 5.3.0, 5.3.1, 5.3.2
>            Reporter: Przemek Bruski
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>         Attachments: BrokerServiceResolveHostTest.java
>
>
> TcpTransport.java contains the following code:
> {code}
>     protected String resolveHostName(String host) throws UnknownHostException {
>         String localName = InetAddress.getLocalHost().getHostName();
>         if (localName != null && isUseLocalHost()) {
>             if (localName.equals(host)) {
>                 return "localhost";
>             }
>         }
>         return host;
>     }
> {code}
> TcpTransportServer.java contains the following code:
> {code}
>         InetAddress addr = InetAddress.getByName(host);
>         try {
>             this.serverSocket = serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
> {code}
> /etc/hosts looks like this:
> {code}
> 127.0.0.1       localhost.localdomain   localhost
> someip       myhostname.mydomain myhostname
> {code}
> Now, if I start server with uri: myhostname.mydomain, the server will listen on someip but the client started on the same host with the same uri will try connect to localhost (and fail).
> I know that useLocalHost can be used to avoid it, but silently connecting to localhost is counterintuitive and does not sound like a valid default behaviour (according to documentation, using localhost instead of the host name is a workaround, the workaround is now effectively default behaviour and breaks valid setups that used to work with 5.2).
> This worked fine on 5.2, since the server bound to all interfaces - but fixing this was obviously the right thing to do.
> Questions:
> 1. Can the default behaviour be changed to one that would work on majority of systems?
> 2. Is the workaround really needed? Maybe it's the local network settings that should be corrected?
> 3. The debug messages are misleading and probably should be changed:
> [ActiveMQ Task] [FailoverTransport:604] urlList connectionList:[tcp://hostname:54663?wireFormat.maxInactivityDuration=300000]
> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000
> [ActiveMQ Task] [FailoverTransport:764] Connect fail to: tcp://hostname:54663?wireFormat.maxInactivityDuration=300000, reason: java.net.ConnectException: Connection refused
> In fact, it was the connection to localhost:54663 that was refused.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.