Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com
 designates 209.85.212.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=dXiAARE9w55VOvO7ASMbSK9gQHi3su6039cVDwPQsvYotfYxTIdNDKCU7AzHb/VleV
         j/5zEkB1+L1Xw/eXI51XX16soMP6B1PT7wF1dz0Q5YA9y4nRoJtro1M8AEYscJhTsZSW
         Ig+xYYZXrQghB3Xm03UR6adUcCgup8Hove0mU=
MIME-Version: 1.0
In-Reply-To: <29306610.post@talk.nabble.com>
References: <1805815.12001276089171820.JavaMail.jira@thor>
	<30854363.56451280485912788.JavaMail.jira@thor>
	<29306610.post@talk.nabble.com>
Date: Fri, 30 Jul 2010 15:58:33 +0100
Message-ID: <AANLkTikFRCVjVDFipdnnVOSOriZPS2qeCwdyFZgbqqrT@mail.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
From: Gary Tully <gary.tully@gmail.com>
To: dev@activemq.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

append the transport options to the uri:

multicast://default?group=3DTestDeCharge-DEFAULT&useLocalHost=3Dfalse

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 :
>
> =A0 =A0 =A0<networkConnector name=3D"TestDeCharge-DEFAULT-OUT"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uri=3D"multicast://default=
?group=3DTestDeCharge-DEFAULT"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0networkTTL=3D"1"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0conduitSubscriptions=3D"fa=
lse"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dynamicOnly=3D"true"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0duplex=3D"false"/>
>
> =3D>
> =A0 =A0 =A0 <networkConnector name=3D"TestDeCharge-DEFAULT-OUT"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uri=3D"multicast://default=
?group=3DTestDeCharge-DEFAULT"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0networkTTL=3D"1"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0conduitSubscriptions=3D"fa=
lse"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dynamicOnly=3D"true"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0duplex=3D"false"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0useLocalHost=3D"false"/>
>
> I don't see this new option of networkConnector in the documentation web
> site.
>
> ???
>
>
> JIRA jira@apache.org wrote:
>>
>>
>> =A0 =A0 [
>> https://issues.apache.org/activemq/browse/AMQ-2771?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D61003=
#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 b=
y
>> the user of that information.
>>
>>> Side effect from AMQ-2094, server listens on host name address, client
>>> connects to localhost with the same URI
>>> -----------------------------------------------------------------------=
---------------------------------------
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: AMQ-2771
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: https://issues.apache.org/activemq=
/browse/AMQ-2771
>>> =A0 =A0 =A0 =A0 =A0 =A0 Project: ActiveMQ
>>> =A0 =A0 =A0 =A0 =A0Issue Type: Wish
>>> =A0 =A0Affects Versions: 5.3.0, 5.3.1, 5.3.2
>>> =A0 =A0 =A0 =A0 =A0 =A0Reporter: Przemek Bruski
>>> =A0 =A0 =A0 =A0 =A0 =A0 Fix For: 5.4.1
>>>
>>> =A0 =A0 =A0 =A0 Attachments: BrokerServiceResolveHostTest.java
>>>
>>>
>>> TcpTransport.java contains the following code:
>>> {code}
>>> =A0 =A0 protected String resolveHostName(String host) throws
>>> UnknownHostException {
>>> =A0 =A0 =A0 =A0 String localName =3D InetAddress.getLocalHost().getHost=
Name();
>>> =A0 =A0 =A0 =A0 if (localName !=3D null && isUseLocalHost()) {
>>> =A0 =A0 =A0 =A0 =A0 =A0 if (localName.equals(host)) {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return "localhost";
>>> =A0 =A0 =A0 =A0 =A0 =A0 }
>>> =A0 =A0 =A0 =A0 }
>>> =A0 =A0 =A0 =A0 return host;
>>> =A0 =A0 }
>>> {code}
>>> TcpTransportServer.java contains the following code:
>>> {code}
>>> =A0 =A0 =A0 =A0 InetAddress addr =3D InetAddress.getByName(host);
>>> =A0 =A0 =A0 =A0 try {
>>> =A0 =A0 =A0 =A0 =A0 =A0 this.serverSocket =3D
>>> serverSocketFactory.createServerSocket(bind.getPort(), backlog, addr);
>>> {code}
>>> /etc/hosts looks like this:
>>> {code}
>>> 127.0.0.1 =A0 =A0 =A0 localhost.localdomain =A0 localhost
>>> someip =A0 =A0 =A0 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 connecti=
ng
>>> to localhost is counterintuitive and does not sound like a valid defaul=
t
>>> 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 settin=
gs
>>> 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=
=3D300000]
>>> [ActiveMQ Task] [FailoverTransport:723] Attempting connect to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=3D300000
>>> [ActiveMQ Task] [FailoverTransport:764] Connect fail to:
>>> tcp://hostname:54663?wireFormat.maxInactivityDuration=3D300000, 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-%28=
AMQ-2771%29-Side-effect-from-AMQ-2094%2C-server-listens-on-host-name-addres=
s%2C-client-connects-to-localhost-with-the-same-URI-tp28830232p29306610.htm=
l
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>


--=20
http://blog.garytully.com

Open Source Integration
http://fusesource.com