GitHub user apurvam opened a pull request:

    https://github.com/apache/kafka/pull/4020

    KAFKA-6003: Accept appends on replicas and when rebuilding the log 
unconditionally

    This is a port of #4004 for the 0.11.0 branch.
    
    With this patch so that we _only_ validate appends which originate
    from the client. In general, once the append is validated and written to
    the leader the first time, revalidating it is undesirable since we can't
    do anything if validation fails, and also because it is hard to maintain
    the correct assumptions during validation, leading to spurious
    validation failures.
    
    For example, when we have compacted topics, it is possible for batches
    to be compacted on the follower but not on the leader. This case would
    also lead to an OutOfOrderSequencException during replication. The same
    applies to when we rebuild state from compacted topics: we would get
    gaps in the sequence numbers, causing the OutOfOrderSequence.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apurvam/kafka 
KAKFA-6003-0.11.0-handle-unknown-producer-on-replica

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/kafka/pull/4020.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #4020
    
----
commit 0a6a0213c091c8e6b6a9c5ce7655b7e0d06c9db0
Author: Apurva Mehta <apu...@confluent.io>
Date:   2017-10-04T20:42:17Z

    KAFKA-6003: Accept appends on replicas and when rebuilding state from
    the log unconditionally.
    
    With this patch so that we _only_ validate appends which originate
    from the client. In general, once the append is validated and written to
    the leader the first time, revalidating it is undesirable since we can't
    do anything if validation fails, and also because it is hard to maintain
    the correct assumptions during validation, leading to spurious
    validation failures.
    
    For example, when we have compacted topics, it is possible for batches
    to be compacted on the follower but not on the leader. This case would
    also lead to an OutOfOrderSequencException during replication. The same
    applies to when we rebuild state from compacted topics: we would get
    gaps in the sequence numbers, causing the OutOfOrderSequence.

----


---

Reply via email to