/*
 * Copyright (c) 2008-2018, Hazelcast, Inc. All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package com.hazelcast.partition;

import com.hazelcast.core.Partition;
import com.hazelcast.core.PartitionService;

import java.util.EventListener;

/**
 * PartitionLostListener provides the ability to be notified upon a possible data loss when a partition has no owner and backups.
 * <p>
 * <b>IMPORTANT:</b> Please note that it may dispatch false-positive partition lost events when partial network split errors
 * occur.
 * <p>
 * Partition loss detection algorithm works as follows:
 * When the cluster is initialized, each node becomes owner of some of the partitions, and backup of the some other partitions.
 * On a node failure, the first backup node becomes owner for a partition and all other backup nodes are shifted up in the
 * partition backup order. Therefore, some nodes sync themselves from the new partition owner node since they are shifted up in
 * the partition table and do not contain the backup data yet. Whey they issue a partition sync request, they set themselves in
 * a custom state that indicates that a node is waiting for a partition sync for a particular backup. When the sync operation is
 * completed, that sync flag is reset.
 * <p>
 * Lets say the owner of the partition crashes before it sends backup data to sync-waiting partitions.
 * The first backup which will become the owner of the partition checks its replica-sync flags. If they are set, it detects that
 * the owner failed before the backup node completes the sync process and issues a partition lost event.
 *
 * @see Partition
 * @see PartitionService
 * @since 3.5
 */
public interface PartitionLostListener extends EventListener {

    /**
     * Invoked when a partition loses its owner and all backups.
     *
     * @param event the event that contains the partition ID and the backup count that has been lost
     */
    void partitionLost(PartitionLostEvent event);
}

@@ -881,510 +881,896 @@
 ion 
-has no owner and backups.%0A * %3Cp%3E%0A * %3Cb%3EIMPORTANT:%3C/b%3E Please note that it may dispatch false-positive partition lost events when partial network split errors%0A * occur.%0A * %3Cp%3E%0A * Partition loss detection algorithm works as follows:%0A * When the cluster is initialized, each node becomes owner of some of the partitions, and backup of the some other partitions.%0A * On a node failure, the first backup node becomes owner for a partition and all other backup nodes are shifted up in the%0A * partition
+loses a replica.%0A * %3Cp%3E%0A * When the cluster is initialized, each node becomes owner of some of the partitions, and backup of the some other partitions.%0A * We call owner of partition %22primary replica%22 and backup nodes %22backup replicas%22. Partition replicas are ordered.%0A * A primary replica node keeps all data that is mapped to the partition. If a Hazelcast data structure is configured with%0A * 1 backup, its data is put into the primary replica and the first backup replica. Similarly, data of a Hazelcast data structure%0A * that is configured with 2 backups is put into the primary replica, the first backup replica, and the second backup replica.%0A * The idea is same for higher backup counts.%0A * %3Cp%3E%0A * When a node fails, primary replicas of its partitions are lost. In this case, ownership of each partition owned by%0A * the unreachable node is transferred to the first available
  backup 
 orde
@@ -1769,30 +1769,44 @@
 kup 
+n
 o
-r
 de
-r
 . 
-Therefore, some
+After this point, other backup
  nod
@@ -1823,16 +1823,19 @@
 emselves
+%0A *
  from th
@@ -1865,675 +1865,1165 @@
 ode 
-s
 in
-ce they are shifted up in%0A * the partition table and do not contain the backup data yet. Whey they issue a partition sync request, they set themselves in%0A * a custom state that indicates that a node is waiting for a partition sync for a particular backup. When the sync operation is%0A * completed, that sync flag is reset.%0A * %3Cp%3E%0A * Lets say the owner of the partition crashes before it sends backup data to sync-waiting partitions.%0A * The first backup which will become the owner of the partition checks its replica-sync flags. If they are set, it detects that%0A * the owner failed before the backup node completes the sync process and issues a partition lost event
+ order to populate the missing backup data.%0A * %3Cp%3E%0A * In this context, the partition loss detection algorithm works as follows:%0A * %7B@link PartitionLostEvent#lostBackupCount%7D denotes the replica index up to the which partition replicas are lost.%0A * - 0 means that only the primary replica is lost. In other words, the node which owns the partition is unreachable,%0A * hence removed from the cluster.%0A * If there is a data structure configured with no backups, its data is lost for this partition.%0A * - 1 means that both the primary replica and the first backup replica are lost. In other words, the partition owner node and%0A * the first backup node have became unreachable. If a data structure is configured with less than 2 backups, its data is lost%0A * for this partition.%0A * - The idea works same for higher backup counts.%0A *%0A * Please note that node failures that do not involve a primary replica does not lead to partition lost events.%0A * For instance, if a backup node crashes when owner of the partition is still alive, a partition lost event is not fired.%0A * In this case, Hazelcast tries to assign a new backup replica to populate the missing backup
 .%0A *

Improve partition lost listener javadoc