activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: ActiveMQConnectionFactory: use initial connectors instead of received topology
Date Thu, 03 Aug 2017 16:44:05 GMT
That would work. 

Sent from my iPhone

> On 3 Aug 2017, at 17:41, Justin Bertram <jbertram@redhat.com> wrote:
> 
> 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.
> 
> 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.
> 
> 
> Justin
> 
> On Thu, Aug 3, 2017 at 11:32 AM, Michael André Pearce <
> michael.andre.pearce@me.com> wrote:
> 
>> 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 in
>> some support licensing as had to reduce cpu counts.
>> 
>> Sent from my iPhone
>> 
>>> On 3 Aug 2017, at 17:31, Michael André Pearce <
>> michael.andre.pearce@me.com> wrote:
>>> 
>>> 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.
>>> 
>>> 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 one
>> 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.
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 3 Aug 2017, at 14:59, Clebert Suconic <clebert.suconic@gmail.com>
>> wrote:
>>>> 
>>>> On Thu, Aug 3, 2017 at 9:01 AM, Michael André 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.
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> 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).
>>>> 
>>>> 
>>>> then you could connect with:
>>>> 
>>>> 
>>>> ActiveMQConnectionFactory factory = new
>>>> ActiveMQConnectionFactory((tcp://NODE1:61616,tcp://NODE2:
>> 61616)?blockOnDurableSend=false&useTopology=false");
>>>> 
>>>> 
>>>> I"m not sure if useTopology would make it clear.. I'm still thinking
>>>> about a better name.
>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 3 Aug 2017, at 12:52, Clebert Suconic <clebert.suconic@gmail.com>
>> wrote:
>>>>>> 
>>>>>> It is not a bug. People use this to feed an initial list than the
>> topology
>>>>>> could be much bigger.
>>>>>> 
>>>>>> On Thu, Aug 3, 2017 at 1:18 AM Michael André Pearce <
>>>>>> michael.andre.pearce@me.com> wrote:
>>>>>> 
>>>>>>> To me this sounds like a bug, where you get two connections because
>> you
>>>>>>> use two lists.
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> Similar to udp discovery it simply discovers then it uses the
>> topology
>>>>>>> returned.
>>>>>>> 
>>>>>>> Sent from my iPad
>>>>>>> 
>>>>>>>> On 3 Aug 2017, at 04:59, Clebert Suconic <clebert.suconic@gmail.com
>>> 
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> I agree we could add an option. We could use the URI parameters
>> Thought
>>>>>>> as
>>>>>>>> a beanUtils?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Wed, Aug 2, 2017 at 11:36 PM Justin Bertram <
>> jbertram@redhat.com>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Justin
>>>>>>>>> 
>>>>>>>>> On Wed, Aug 2, 2017 at 9:28 AM, cjaniake <
>> christian.janiake@movile.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 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 first
>>>>>>>>> (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.
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>>> Thank you very much.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> --
>>>>>>>> Clebert Suconic
>>>>>>> 
>>>>>> --
>>>>>> Clebert Suconic
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Clebert Suconic
>> 

Mime
View raw message