Ok, I will rename the metrics.
2017-11-24 22:55 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> Got it, but I do not like the name of the metric, I think it is confusing.
>
> I would provide the following metrics:
> - minNumberOfCopies()
> - maxNumberOfCopies()
>
> Will this work for you?
>
> D.
>
> On Thu, Nov 23, 2017 at 10:38 PM, Alex Plehanov <plehanov.a...@gmail.com>
> wrote:
>
> > We have target redundancy level - 4. If, for some reason, minimal
> > redundancy level reached the value of 1, then each next node left the
> > cluster may cause data loss or service unavailability.
> >
> > 2017-11-24 1:31 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> >
> > > Alex,
> > >
> > > I am really confused. What do you need to know the "minimal partition
> > > redundancy" for? What will it give you?
> > >
> > > D.
> > >
> > > On Thu, Nov 23, 2017 at 2:25 PM, Alex Plehanov <
> plehanov.a...@gmail.com>
> > > wrote:
> > >
> > > > Example was in my previous letters: if we have in our cluster for
> cache
> > > > group one partition with 2 copies (1 primary and 1 backup) and other
> > > > partitions with 4 copies (1 primary and 3 backups), then minimal
> > > partition
> > > > redundancy level for this cache group will be 2.
> > > >
> > > > Maybe code will be more clear than my description, I think it will be
> > > > something like that:
> > > >
> > > > for (int part = 0; part < partitions; part++) {
> > > > int partRedundancyLevel = 0;
> > > >
> > > > for (Map.Entry<UUID, GridDhtPartitionMap> entry :
> > > > partFullMap.entrySet()) {
> > > > if (entry.getValue().get(part) ==
> > > > GridDhtPartitionState.OWNING)
> > > > partRedundancyLevel++;
> > > > }
> > > >
> > > > if (partRedundancyLevel < minRedundancyLevel)
> > > > minRedundancyLevel = partRedundancyLevel;
> > > > }
> > > >
> > > >
> > > > 2017-11-23 4:04 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> > > >
> > > > > I think you are talking about the case when cluster temporarily
> gets
> > > into
> > > > > unbalanced state and needs to rebalance. However, I am still not
> sure
> > > > what
> > > > > this metric would show. Can you provide an example?
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Nov 22, 2017 at 2:10 PM, Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > It's not about caches.
> > > > > > Each partition has certain amount of copies. Amount of copies may
> > > > differ
> > > > > > for different partitions of one cache group.
> > > > > >
> > > > > > This configuration possible:
> > > > > > 1) With custom affinity function
> > > > > > 2) When nodes left the cluster, till rebalancing is not finished
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2017-11-23 0:18 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > > >
> > > > > > > On Wed, Nov 22, 2017 at 12:39 PM, Alex Plehanov <
> > > > > plehanov.a...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello Dmitriy,
> > > > > > > >
> > > > > > > > I agree.
> > > > > > > >
> > > > > > > > By "minimal partition redundancy level for cache group" I
> mean
> > > > > minimal
> > > > > > > > number of partition copies among all partitions of this cache
> > > > group.
> > > > > > > > For example, if we have in our cluster for cache group one
> > > > partition
> > > > > > > with 2
> > > > > > > > copies (1 primary and 1 backup) and other partitions with 4
> > > copies
> > > > (1
> > > > > > > > primary and 3 backups), then minimal partition redundancy
> level
> > > for
> > > > > > this
> > > > > > > > cache group will be 2.
> > > > > > > >
> > > > > > >
> > > > > > > Such configuration within the same group would be impossible.
> All
> > > > > caches
> > > > > > > within the same group have identical total number of partitions
> > and
> > > > > > > identical number of backups. If that is not the case, then they
> > > fall
> > > > > into
> > > > > > > different groups.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
