hi Val, Another question about point 3: Event with user attributes, but when do the deployment of adding new machines to the node, it will roll out one machine group by one, so this means during the period of deployment, all the nodes cannot get the same user attributes (machines group info) and if the Rendezvous hashing return a new machine list for one partition with a new machine in the top N (N is the backup # + 1), the backup filter in different nodes may made different decision.
E.g. for partition p of cache c, its node list after Rendezvous hashing is A1, X1, B2, C3, D2, ..., where letter is machine and digit is group; and X is a new added machine and for rolled machine, its group is 1 but for others, it's unknown; and suppose the backup = 2. Say, we've rolled out group 1 and are rolling out group 2 now, so in machine A, it selects (A1, B2, C3), but in machine C, it may select (A1, X, B2), because it doesn't know which group X belongs to now. This will cause inconsistency. And we must ensure no data loss in the memory only. BTW, do you have any successful case for this usage scenario? how do you resolve this problem? Thanks, -Jason -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/How-to-use-the-logger-in-the-BackupFilter-tp6442p6499.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
