Did a partial review, left one comment on the PR.
We need another pair of eyes on this for sure.
On Wed, Oct 16, 2019 at 10:34 AM Alex Plehanov
wrote:
> Hello guys,
>
>
> I've implemented affinity awareness support for java thin client [1]. There
> is only client-side affected by the patch. Can
Hello guys,
I've implemented affinity awareness support for java thin client [1]. There
is only client-side affected by the patch. Can anyone review the change?
1: https://issues.apache.org/jira/browse/IGNITE-11898
ср, 13 мар. 2019 г. в 22:54, Pavel Tupitsyn :
> Default value for boolean is
Default value for boolean is false, and I though we'll have the feature
enabled by default.
But I agree with you. Let's disable by default and name the config property
EnableAffinityAwareness.
On Wed, Mar 13, 2019 at 12:52 PM Igor Sapego wrote:
> For the "false" I mean "disable" here.
>
> BTW, I
For the "false" I mean "disable" here.
BTW, I believe we should name this parameter in a positive way:
EnableAffinityAwareness, not disable.
Best Regards,
Igor
On Wed, Mar 13, 2019 at 12:50 PM Igor Sapego wrote:
> Well, yes, this looks like a simplest solution. Let's implement it for the
> be
Well, yes, this looks like a simplest solution. Let's implement it for the
beginning and set this feature to "false" by default, as this feature looks
complex, probably error-prone, and should be considered in a "beta"
state for the first release.
Best Regards,
Igor
On Mon, Mar 11, 2019 at 8:04
My suggestion is a boolean flag in client configuration:
DisableAffinityAwareness
And use old random/round-robin behavior with only one active connection.
On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego wrote:
> Pavel,
>
> That's right. Do you have other suggestions or objections?
>
> Best Regards,
Pavel,
That's right. Do you have other suggestions or objections?
Best Regards,
Igor
On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn wrote:
> > maxConnectionNumber parameter
> What's the idea? Follow the Best Effor Affinity logic, but establish up to
> N connections?
>
> On Thu, Mar 7, 2019 a
> maxConnectionNumber parameter
What's the idea? Follow the Best Effor Affinity logic, but establish up to
N connections?
On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego wrote:
> I can propose two improvements here:
>
> 1. A simple one. Lets introduce maxConnectionNumber parameter
> in ClientConfigu
I can propose two improvements here:
1. A simple one. Lets introduce maxConnectionNumber parameter
in ClientConfiguration. As it is easy to implement it may be introduced
together with the new feature to give user an additional control.
2. Asynchronous connection establishment. In this case start
Hi,
I'm in progress of implementing this IEP for Ignite.NET, and I have
concerns about the following:
> On thin client startup it connects to all nodes provided by client
configuration
Should we, at least, make this behavior optional?
One of the benefits of thin client is quick startup/connect
Guys, I've updated the IEP page [1] once again.
Please, pay attention to sections Cache affinity mapping acquiring
(4.a, format of Cache Partitions Request) and Changes to cache
operations with single key (3 and 4, algorithm).
Long story short, I've decided to add some additional data to Cache
Pa
Looks good to me.
On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego wrote:
> I've updated IEP page: [1]
>
> What do you think now? To me it looks cleaner.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On M
I've updated IEP page: [1]
What do you think now? To me it looks cleaner.
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Best Regards,
Igor
On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego wrote:
> Ok, I understand now. I'll try updating IE
Ok, I understand now. I'll try updating IEP according to this proposal and
notify you guys.
Best Regards,
Igor
On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov wrote:
> Igor,
>
> My idea is simply to add the list of caches with the same distribution to
> the end of partition response. Client can
Igor,
My idea is simply to add the list of caches with the same distribution to
the end of partition response. Client can use this information to populate
partition info for more caches in a single request.
On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego wrote:
> Vladimir,
>
> So correct me if I'm w
Vladimir,
So correct me if I'm wrong, what you propose is to avoid mentioning
of cache groups, and use instead of "cache group" term something like
"distribution"? Or do you propose some changes in protocol? If so, can
you briefly explain, what kind of changes they are?
Best Regards,
Igor
On Mo
Igor,
Yes, cache groups are public API. However, we try to avoid new APIs
depending on them.
The main point from my side is that “similar cache group” can be easily
generalized to “similar distribution”. This way we avoid cache groups on
protocol level at virtually no cost.
Vladimir.
пн, 4 февр.
Guys,
Can you explain why do we want to avoid Cache groups in protocol?
If it's about simplicity of the protocol, then removing cache groups will
not help much with it - we will still need to include "knownCacheIds"
field in request and "cachesWithTheSamePartitioning" field in response.
And also,
Pavel, Igor,
This is not very accurate to say that this will not save memory. In
practice we observed a number of OOME issues on the server-side due to many
caches and it was one of motivations for cache groups (another one disk
access optimizations). On the other hand, I agree that we'd better to
Igor, I have a feeling that we should omit Cache Group stuff from the
protocol.
It is a rare use case and even then dealing with them on client barely
saves some memory.
We can keep it simple and have partition map per cacheId. Thoughts?
On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego wrote:
> Guys,
Guys, I've updated the proposal once again [1], so please,
take a look and let me know what you think.
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Best Regards,
Igor
On Thu, Jan 17, 2019 at 1:05 PM Igor Sapego wrote:
> Yeah, I'll ad
Yeah, I'll add it.
Best Regards,
Igor
On Wed, Jan 16, 2019 at 11:08 PM Pavel Tupitsyn
wrote:
> > to every server
> I did not think of this issue. Now I agree with your approach.
> Can you please add an explanation of this to the IEP?
>
> Thanks!
>
> On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego
> to every server
I did not think of this issue. Now I agree with your approach.
Can you please add an explanation of this to the IEP?
Thanks!
On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego wrote:
> Pavel,
>
> Yeah, it makes sense, but to me it seems that this approach can lead
> to more complica
Pavel,
Yeah, it makes sense, but to me it seems that this approach can lead
to more complicated client logic, as it will require to make additional call
to every server, that reports affinity topology change.
Guys, WDYT?
Best Regards,
Igor
On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn
wrote
Igor,
> It is proposed to add flag to every response, that shows whether the
Affinity Topology Version of the cluster has changed since the last request
from the client.
I propose to keep this flag. So no need for periodic checks. Makes sense?
On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego wrote:
Pavel,
This will require from client to send this new request periodically, I'm not
sure this will make clients simpler. Anyway, let's discuss it.
Vladimir,
With current proposal, we will have affinity info in message header.
Best Regards,
Igor
On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov
Igor,
I think that "Cache Partitions Request" should contain affinity topology
version. Otherwise we do not know what distribution is returned - the one
we expected, or some newer one. The latter may happen in case topology
changed or late affinity assignment happened between server response and
s
Hi Igor,
Looks good to me in general, except changing the response message format so
much.
Can we use a separate message to retrieve affinity topology version?
Set a flag as you describe, but don't put the version data into standard
response?
Just to keep the protocol cleaner, follow SRP to some
Hello guys,
I've updated IEP page [1] describing proposed solution in more details and
proposing some changes for a protocol.
Please, take a look and let me know what you think.
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Best Regards
Denis,
Yes, in principle we can extend it. We are going to implement it in
subsequent phases of this IEP.
On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan
wrote:
> On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda wrote:
>
> > Folks,
> >
> > Feel that this functionality can be extended to the au
On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda wrote:
> Folks,
>
> Feel that this functionality can be extended to the automatic reconnect,
> can't it? Presently we require to provide a static list of IPs to be used
> at a reconnect time. By having a partition map of all the nodes, the thin
> clie
Folks,
Feel that this functionality can be extended to the automatic reconnect,
can't it? Presently we require to provide a static list of IPs to be used
at a reconnect time. By having a partition map of all the nodes, the thin
client should be able to automate this piece.
--
Denis
On Mon, Jun 1
I've created an IEP: [1]
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Best Regards,
Igor
On Thu, Jun 14, 2018 at 4:17 PM Pavel Tupitsyn wrote:
> Ok, I see, this is what I was trying to understand, and this is an
> important note I thi
Ok, I see, this is what I was trying to understand, and this is an
important note I think:
* We should request AffinityFunction for each particular cache and only
enable this functionality for known functions
* Make sure that known server-side functions never change their behavior
Thanks
On Thu,
Vladimir is right,
As far as I know, most users use affinity functions provided by Ignite.
So we could optimize for the default case and, in future, optionally,
let user implement their own AffinityFunction for thin clients.
Best Regards,
Igor
On Thu, Jun 14, 2018 at 3:06 PM Vladimir Ozerov
wr
Pavel,
The idea here is that optimization will be applicable only for well-known
affinity functions. E.g., we know that for rendezvous affinity, partition
is "hash(key) % partitions". This is all we need to make default affinity
work.
On Thu, Jun 14, 2018 at 11:41 AM, Pavel Tupitsyn
wrote:
> Af
AffinityFunction interface has the following method:
int partition(Object key)
User calls cache.put(x,y) from the client.
In order to calculate the target node we have to call that partition method,
and then use partition map to get the node by partition.
But client does not have AffinityFunctio
Denis, that's right.
Best Regards,
Igor
On Wed, Jun 13, 2018 at 10:58 PM Denis Magda wrote:
> Pavel,
>
> Most likely the client will be pulling the partitioning map periodically.
> If the local map is outdated, it won't be a big deal because a server node
> that receives a request:
>
>- ca
Pavel,
Most likely the client will be pulling the partitioning map periodically.
If the local map is outdated, it won't be a big deal because a server node
that receives a request:
- can redirect it to a map that owns a partition
- will add an updated partition map to the client's response
Hi Igor,
How can we invoke the affinity function on the client, if we don't have the
implementation at hand?
Am I missing something?
Thanks,
Pavel
On Wed, Jun 13, 2018 at 5:34 PM, Igor Sapego wrote:
> Hi, Igniters,
>
> Currently, I'm working on the thin C++ client implementation.
> As you may
40 matches
Mail list logo
