[
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 <[email protected]>
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)
