You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/05/16 22:29:13 UTC

[jira] [Commented] (KAFKA-3716) Check against negative timestamps

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

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

GitHub user guozhangwang opened a pull request:

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

    KAFKA-3716: Validate all timestamps are not negative

    

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

    $ git pull https://github.com/guozhangwang/kafka K3716-check-non-negative-timestamps

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

    https://github.com/apache/kafka/pull/1393.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 #1393
    
----
commit 750dfc96d5a73ed1e252b0cd6b1ba1c2a37e5f32
Author: Guozhang Wang <wa...@gmail.com>
Date:   2016-05-16T22:26:59Z

    validate all timestamps are not negative

----


> Check against negative timestamps
> ---------------------------------
>
>                 Key: KAFKA-3716
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3716
>             Project: Kafka
>          Issue Type: Bug
>          Components: streams
>            Reporter: Guozhang Wang
>            Assignee: Guozhang Wang
>              Labels: architecture, user-experience
>
> Although currently we do not enforce any semantic meaning on the {{Long}} typed timestamps, we are actually assuming it to be non-negative while storing the timestamp in windowed store. For example, in {{RocksDBWindowStore}} we store the timestamp as part of the key, and relying on RocksDB's default lexicographic byte array comparator, and hence negative long value stored in RocksDB will cause the range search ordering to be messed up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)