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.pea...@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.suco...@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 <jbert...@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.jani...@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
