[ 
https://issues.apache.org/jira/browse/KAFKA-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873354#comment-15873354
 ] 

ASF GitHub Bot commented on KAFKA-4776:
---------------------------------------

GitHub user hachikuji opened a pull request:

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

    KAFKA-4776: Implement graceful handling for improperly formed compressed 
message sets

    

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

    $ git pull https://github.com/hachikuji/kafka KAFKA-4776

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

    https://github.com/apache/kafka/pull/2572.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 #2572
    
----
commit 7402b3c0e079a2f033b642aad7ae6c113015ab49
Author: Jason Gustafson <ja...@confluent.io>
Date:   2017-02-18T22:21:52Z

    KAFKA-4776: Implement graceful handling for improperly formed compressed 
message sets

----


> Implement graceful handling for improperly formed compressed message sets
> -------------------------------------------------------------------------
>
>                 Key: KAFKA-4776
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4776
>             Project: Kafka
>          Issue Type: Bug
>          Components: log
>    Affects Versions: 0.10.0.0, 0.10.0.1, 0.10.1.0, 0.10.1.1, 0.10.2.0
>            Reporter: Jason Gustafson
>            Assignee: Jason Gustafson
>            Priority: Minor
>
> This affects validation of compressed message sets. It is possible for a 
> buggy client to send both a null compressed message set (i.e. a wrapper 
> message with a null value), and an empty compressed message set (i.e. a 
> wrapper message with valid compressed data in the value field, but no actual 
> records). In both cases, this causes an unexpected exception raised from the 
> deep iteration, which is returned to the client as an UNKNOWN_ERROR. It would 
> be better to return a CORRUPT_MESSAGE error.
> Note also that the behavior of the empty case was potentially more 
> problematic in versions prior to 0.10.2.0. Although we properly handled the 
> null case, the broker would accept the empty message set and write it to the 
> log. The impact of this appears to be minor, but may cause unexpected 
> behavior in cases where we assume compressed message sets would contain some 
> records.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to