[
https://issues.apache.org/jira/browse/MESOS-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355643#comment-17355643
]
Andrei Sekretenko commented on MESOS-10216:
-------------------------------------------
Fixed in the master/1.12 by https://github.com/apache/mesos/pull/386
Now, we need a decision on whether this needs to be backported. Things to
consider:
- The fix in #386 is backward-compatible for a non-overflowed log
- The issue has been present since 0.16.0
- The fix alters the read behavior in case of overflowed positions. However,
I'm not sure how any sane behavior could have been possible before the fix in
the overflow case: looks like the metadata was guaranteed to be overwritten,
wasn't it?
[~cf.natali] [~ipronin] Thoughts?
> Replicated log key encoding overflows into negative values
> ----------------------------------------------------------
>
> Key: MESOS-10216
> URL: https://issues.apache.org/jira/browse/MESOS-10216
> Project: Mesos
> Issue Type: Bug
> Components: replicated log
> Affects Versions: 1.11.0
> Reporter: Ilya
> Assignee: Charles Natali
> Priority: Major
>
> LevelDB keys used by {{LevelDBStorage}} are {{uint64_t}} log positions
> encoded as strings and padded with zeroes up to a certain fixed size. The
> {{encode()}} function is incorrect because it uses the {{%d}} formatter that
> expects an {{int}}. It also limits the key size to 10 digits which is OK for
> {{UINT32_MAX}} but isn't enough for {{UINT64_MAX}}.
> Because of this the available key range is reduced, and key overflow can
> result in replica's {{METADATA}} record (position 0) being overwritten, which
> in turn may cause data loss.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
