activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: [jira] Commented: (AMQ-2771) Side effect from AMQ-2094, server listens on host name address, client connects to localhost with the same URI
Date Fri, 30 Jul 2010 14:58:33 GMT
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

Mime
View raw message