BLAT sounds good to me because it slightly funny in case you speak russian.
"Node joined topology by BLAT (po blaty)" sounds reasonable :)
чт, 24 мая 2018 г. в 1:15, Dmitriy Setrakyan :
> Ed,
>
> Anyone speaking Russian would agree that BLAT is not a good name :) Let's
>
Ed,
Anyone speaking Russian would agree that BLAT is not a good name :) Let's
steak to BLT.
D.
On Wed, May 23, 2018 at 5:34 AM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:
> Igniters,
>
> We have invested too much in explaining BLAT. So, it would hard to change
> the name.
> I.e. I
I do not like the name "current" on the methods. I think we should just
remove it, e.g. currentAffinityTopology() -> affinityTopology()
D.
On Fri, May 4, 2018 at 6:17 AM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:
> Igniters,
>
> With Vladimir's help, we analyzed another solution's
Igniters,
With Vladimir's help, we analyzed another solution's approaches.
And decided to simplify our affinity topology auto-adjusting.
It should be enough to be able to turn on/off auto-adjusting (flag) and set
2 timeouts if it is working:
-soft timeout which would be used if there was no
Eduard,
+1 to your proposed API for configuring Affinity Topology change policies.
Obviously we should use "auto" as default behavior. I believe, automatic
rebalancing is expected and more convenient for majority of users.
Best Regards,
Ivan Rakov
On 26.04.2018 19:27, Eduard Shangareev
Guys,
I would start with estimating efforts rather than with release numbers. I
am not aware of any pressure or deadlines for AI 2.5. On the other hand
current behavior causes a lot of difficulties to our users and it is better
to focus on how to restore original behavior in the product ASAP. It
Igniters,
Ok, I want to share my thoughts about "affinity topology (AT) changing
policies".
There would be three major option:
-auto;
-manual;
-custom.
1. Automatic change.
A user could set timeouts for:
a. change AT on any topology change after some timeout (setATChangeTimeout
in seconds);
b.
Dmitriy,
I also think that we should think about 2.6 as the target.
On Thu, Apr 26, 2018 at 3:27 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Dmitriy,
>
> I doubt we will be able to fit this in 2.5 given that we did not even agree
> on the policy interface. Forcing in-memory
Dmitriy,
I doubt we will be able to fit this in 2.5 given that we did not even agree
on the policy interface. Forcing in-memory caches to use baseline topology
will be an easy technical fix, however, we will need to update and probably
fix lots of failover tests, add new ones.
I think it makes
Eduard,
I'm not sure I understand what you mean by "policy". Is it an interface
that will have a few default implementations and user will be able to
create his own one? If so, could you please write an example of such
interface (how you see it) and how and when it's methods will be invoked.
On
Ed, how difficult is this fix? Are you suggesting it for 2.5?
On Thu, Apr 26, 2018 at 3:10 AM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:
> Igniters,
> I have described the issue with current approach in "New definition for
> affinity node (issues with baseline)" topic[1].
>
> Now
11 matches
Mail list logo