Just catching up on this. Firstly I don't think this is a bug. The static
connector list is used for discovery, not for defining a set of brokers to
round robin over, I agree it's a limitation when used in conjunction with
the out of the box round robin policy. However, it works just fine with
U
That looks like a good approach to me.
Justin
On Thu, Aug 3, 2017 at 2:02 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:
> That's fair enough.
>
> Going with then the other option of skipping the node if it's next in the
> list. That works if the node comes back in the first pos
That's fair enough.
Going with then the other option of skipping the node if it's next in the list.
That works if the node comes back in the first position but you'll still end up
with the same problem if it is in the second position.
Eg initial node order:
A B C
Topology
B A C
First three
As stated previously, I'm not in favor of using the initial connection only
for discovery as I think it's wasteful.
Justin
On Thu, Aug 3, 2017 at 12:41 PM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:
> How much would it be for it to also only use the topology eg the solution
> th
How much would it be for it to also only use the topology eg the solution that
just uses the first connection for discovery only, and then topology for the
actual connections, as so then at least support expanding the cluster also but
also load balancing better the initial connections. That way
I see your point. I supposed I was focusing on the title of his message
(i.e. "use initial connectors instead of received topology") rather than
the the details in the description of his problem.
FWIW, I plan on implementing a new connector parameter to support ignoring
the topology because I thi
From what I read the double connection due to using both lists is the
underlying issue from the original mail.
"
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 usi
That would work.
Sent from my iPhone
> On 3 Aug 2017, at 17:41, Justin Bertram 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
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
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
> wrote:
>
> The bit I'm
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
On Thu, Aug 3, 2017 at 9:01 AM, Michael André Pearce
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 poi
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.
Sent from my iPhone
> On 3 Aug 2017, at 12:52, Clebert Suconic wrote:
>
> It is not a bug. Peo
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
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 reconnec
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 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
>
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
wrote:
> Hi th
17 matches
Mail list logo
