Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
From: =?utf-8?Q?Michael_Andr=C3=A9_Pearce?= <michael.andre.pearce@me.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (1.0)
Date: Thu, 03 Aug 2017 17:44:05 +0100
Subject: Re: ActiveMQConnectionFactory: use initial connectors instead of
 received topology
Message-id: <D7700785-2EA6-4C46-9C3E-F8367033E960@me.com>
References: <1501684086948-4729166.post@n4.nabble.com>
 <CAF+kE=RYGnUsGeatmFQaEnadDHeT6Qi4-GyyayfQnhJ7g_-dYQ@mail.gmail.com>
 <CAKF+bsrrF68GCVDh9C8yF3+2iu40EwiQ1CAO9c+gz9tjaJDBOQ@mail.gmail.com>
 <1E5E2643-263C-431D-944B-FDA6519F6C00@me.com>
 <CAKF+bsqo=u2zpsXW37+HoBfSRUALvwpqZgwsZwFmizKSUS81aw@mail.gmail.com>
 <94EB55D7-AFBC-4B94-B80E-CD1E1AA68A96@me.com>
 <CAKF+bso+hJU8Gcy2kFSM9=97QwAS824O-9EqGUEML_P3=_KUVg@mail.gmail.com>
 <CBE7C8E4-D361-4C76-B81D-6EB70728A141@me.com>
 <B5311273-A07D-468F-B07C-9723FF45747C@me.com>
 <CAF+kE=QMgLcqvBywqdSB1fBa5Kof13ZZAjiUC37otf4akzjF0A@mail.gmail.com>
In-reply-to: 
 <CAF+kE=QMgLcqvBywqdSB1fBa5Kof13ZZAjiUC37otf4akzjF0A@mail.gmail.com>
To: users@activemq.apache.org
archived-at: Thu, 03 Aug 2017 16:44:17 -0000

That would work.=20

Sent from my iPhone

> On 3 Aug 2017, at 17:41, Justin Bertram <jbertram@redhat.com> wrote:
>=20
> IMO the way to deal with this is to just add a bit of logic so you don't
> get 2 consecutive connections to the same host.  Making a connection with
> the static connectors, getting the topology, closing the connection, and
> then making another connection with the topology is wasteful.
>=20
> In any case, an option not to use the topology at all would be useful.
> That is, after all, what this thread is really about.
>=20
>=20
> Justin
>=20
> On Thu, Aug 3, 2017 at 11:32 AM, Michael Andr=C3=A9 Pearce <
> michael.andre.pearce@me.com> wrote:
>=20
>> We saw this too when running cluster mode and static discovery before we
>> moved to UDP and then finally went to single master cluster due to cost i=
n
>> some support licensing as had to reduce cpu counts.
>>=20
>> Sent from my iPhone
>>=20
>>> On 3 Aug 2017, at 17:31, Michael Andr=C3=A9 Pearce <
>> michael.andre.pearce@me.com> wrote:
>>>=20
>>> The bit I'm getting at is it uses the discovery connection when on
>> static instead of discovering getting the topology and then using that to=

>> make the connection.
>>>=20
>>> This is why when using topology and static you see first two connections=

>> to same host as it uses the discovery connection first which for sake of
>> discussing host a is first in list, and then the next uses the topology o=
ne
>> where host a is first in list as such this is why it makes to connections=

>> to host a before it makes one to host b.
>>>=20
>>>=20
>>>=20
>>> Sent from my iPhone
>>>=20
>>>> On 3 Aug 2017, at 14:59, Clebert Suconic <clebert.suconic@gmail.com>
>> wrote:
>>>>=20
>>>> On Thu, Aug 3, 2017 at 9:01 AM, Michael Andr=C3=A9 Pearce
>>>> <michael.andre.pearce@me.com> wrote:
>>>>> But what I'm saying is should it be that the discovery should happen
>> but then the real connection is made from the returned topology. Like for=

>> UDP instead of hoodwinking on the discovery connection.
>>>>=20
>>>> I'm not understanding your point here? the connection factory will
>>>> always receive a list of the topology (No matter if UDP or TCP) and
>>>> load balance based on the topology returned.
>>>> There are users using this as a feature.
>>>>=20
>>>>=20
>>>>=20
>>>> What I think is needed here is a simple property to the connection
>>>> factory, like.... useTopololgy, connectOntTopology (or please help me
>>>> find a better name).
>>>>=20
>>>>=20
>>>> then you could connect with:
>>>>=20
>>>>=20
>>>> ActiveMQConnectionFactory factory =3D new
>>>> ActiveMQConnectionFactory((tcp://NODE1:61616,tcp://NODE2:
>> 61616)?blockOnDurableSend=3Dfalse&useTopology=3Dfalse");
>>>>=20
>>>>=20
>>>> I"m not sure if useTopology would make it clear.. I'm still thinking
>>>> about a better name.
>>>>=20
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>>> On 3 Aug 2017, at 12:52, Clebert Suconic <clebert.suconic@gmail.com>
>> wrote:
>>>>>>=20
>>>>>> It is not a bug. People use this to feed an initial list than the
>> topology
>>>>>> could be much bigger.
>>>>>>=20
>>>>>> On Thu, Aug 3, 2017 at 1:18 AM Michael Andr=C3=A9 Pearce <
>>>>>> michael.andre.pearce@me.com> wrote:
>>>>>>=20
>>>>>>> To me this sounds like a bug, where you get two connections because
>> you
>>>>>>> use two lists.
>>>>>>>=20
>>>>>>> as in why doesn't it use the topology list straight away? Fair
>> enough for
>>>>>>> discovery of that topology is should temporarily make a connection
>> using
>>>>>>> the static connections, but it should disconnect and reconnect using=

>> the
>>>>>>> topology. I.e. It should just discover the topology using the static=

>>>>>>> discovery list.
>>>>>>>=20
>>>>>>> Similar to udp discovery it simply discovers then it uses the
>> topology
>>>>>>> returned.
>>>>>>>=20
>>>>>>> Sent from my iPad
>>>>>>>=20
>>>>>>>> On 3 Aug 2017, at 04:59, Clebert Suconic <clebert.suconic@gmail.com=

>>>=20
>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>> I agree we could add an option. We could use the URI parameters
>> Thought
>>>>>>> as
>>>>>>>> a beanUtils?
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Wed, Aug 2, 2017 at 11:36 PM Justin Bertram <
>> jbertram@redhat.com>
>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>> I agree there should be an option to stick with the "initial"
>> connectors
>>>>>>>>> rather than being forced to use the topology.  This would be an
>> option
>>>>>>> on
>>>>>>>>> the Netty connector.  I think "useTopology" (defaults to true)
>> would be
>>>>>>> a
>>>>>>>>> good name.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Justin
>>>>>>>>>=20
>>>>>>>>> On Wed, Aug 2, 2017 at 9:28 AM, cjaniake <
>> christian.janiake@movile.com>
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Hi there, I have been using the ActiveMQ Artemis JMS interface
>> without
>>>>>>>>>> JNDI.
>>>>>>>>>> We are not using server discovery, we use static connectors
>> instead.
>>>>>>>>>> In the connection factory configuration we supply a list of
>> hosts, that
>>>>>>>>> are
>>>>>>>>>> located on two different datacenters, acting as two different
>> clusters.
>>>>>>>>>> Using the RoundRobinConnectionLoadBalancingPolicy we expected to
>>>>>>> connect
>>>>>>>>>> to
>>>>>>>>>> every server on the list, but that was not what happened.
>>>>>>>>>> Debugging the code we realized that, after connecting to the firs=
t
>>>>>>>>> (random)
>>>>>>>>>> host on the list, the Server Locator do not use the initial
>> connectors
>>>>>>>>> list
>>>>>>>>>> anymore, it uses the received topology for the next connections.
>>>>>>>>>> We understand this might be useful in simpler scenarios, but this=

>> is
>>>>>>> not
>>>>>>>>>> working for us.
>>>>>>>>>> On a sandbox environment we have even tried to remove the cluster=

>>>>>>>>>> connection
>>>>>>>>>> configuration, for the servers to act on a stadalone manner, but
>> even
>>>>>>>>>> though
>>>>>>>>>> the server locator acts the same way, receiving a "topology" of
>> only
>>>>>>> one
>>>>>>>>>> node and restrict the next connections this one host.
>>>>>>>>>>=20
>>>>>>>>>> There is a number of problems and inneficiencies we see on this
>>>>>>> approach.
>>>>>>>>>> If we have a cluster with 3 hosts for example, and we declare
>> those on
>>>>>>>>> the
>>>>>>>>>> host list and get 3 connections using the round robin policy, we
>> would
>>>>>>>>>> expect to get one connection for each host. But that's not what
>>>>>>> happens.
>>>>>>>>>> The
>>>>>>>>>> load balancing policy starts iterating over one list (the initial=

>>>>>>>>> connector
>>>>>>>>>> list) and after the first successfull connection it continues
>> iterating
>>>>>>>>>> over
>>>>>>>>>> another list (the received topology), so most of the time you
>> would get
>>>>>>>>> two
>>>>>>>>>> connections to the same host and none for one of them.
>>>>>>>>>>=20
>>>>>>>>>> In a scenario like we have here, with two clusters in different
>>>>>>>>> locations,
>>>>>>>>>> it is even worse.
>>>>>>>>>> We would like to know if we there is an option other than
>> creating a
>>>>>>>>>> connection factory for each host we want to use, and if we can
>> propose
>>>>>>> an
>>>>>>>>>> improvement.
>>>>>>>>>> We are willing to contribute with the development, if we have an
>>>>>>>>>> understanding on a possible solution for that problem.
>>>>>>>>>>=20
>>>>>>>>>> Thank you very much.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://activemq.2283324.n4.
>> nabble.com/
>>>>>>>>>> ActiveMQConnectionFactory-use-initial-connectors-instead-of-
>>>>>>>>>> received-topology-tp4729166.html
>>>>>>>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.=

>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Clebert Suconic
>>>>>>>=20
>>>>>> --
>>>>>> Clebert Suconic
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Clebert Suconic
>>=20