;>>>>> returned.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Sent from my iPad
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On 3 Aug 2017, at 04:59, Clebert Suconic <
&g
the URI
> parameters
> >>>>>> Thought
> >>>>>>>>>>> as
> >>>>>>>>>>>> a beanUtils?
> >>>>>>>>>>>>
> >>>>
t;>>>>>>>>
>>>>>>>>>>>>> I agree there should be an option to stick with the "initial"
>>>>>> connectors
>>>>>>>>>>>>> rather than being forced to use the topology. This woul
k "useTopology" (defaults to true)
> >>>> would be
> >>>>>>>>> a
> >>>>>>>>>>> good name.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>&
>
>>>>>>>>>>>> Hi there, I have been using the ActiveMQ Artemis JMS interface
>>>> without
>>>>>>>>>>>> JNDI.
>>>>>>>>>>>> We are not using server discovery, we use static connectors
>
; >>>>>>>>> are
> >>>>>>>>>> located on two different datacenters, acting as two different
> >> clusters.
> >>>>>>>>>> Using the RoundRobinConnectionLoadBalancingPolicy
t 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
onnecting 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
>>
t;>>>>> 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
> >
gt;>>>>>>> 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
t; 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 se
t;>>>> 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
. 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
>>>&
on 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
> >
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
ost 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
e 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.
>
tionFactory-use-initial-connectors-instead-of-received-topology-tp4729166.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
18 matches
Mail list logo
