[
https://issues.apache.org/jira/browse/METRON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722654#comment-15722654
]
ASF GitHub Bot commented on METRON-610:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/388
Is there not a way to ensure that our code uses a single version of the
t-digest library? I'd be worried that we might run into another
incompatibility in the future.
If not, is there some ingenious way to automate the testing of this
scenario?
> OnlineStatisticsProvider serialization is broken at random in the REPL
> ----------------------------------------------------------------------
>
> Key: METRON-610
> URL: https://issues.apache.org/jira/browse/METRON-610
> Project: Metron
> Issue Type: Bug
> Reporter: Casey Stella
> Assignee: Casey Stella
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> We rely on the t-digest library version 3.1 and elasticsearch brings along
> 3.0. There is a small API incompatibility between the two versions (namely
> the static method TDigest.createAvlTreeDigest() is available in 3.1 but not
> 3.0).
> If the classpath for the Stellar REPL chooses the 3.0 version of the library,
> then deserialization is broken.
> Strictly speaking this is not a problem of the serialized form being
> incorrect, but a problem in the custom kryo serialization code in the class.
> It relies on the default constructor being called and then the digest being
> deserialized using the code within the t-digest library. Because the default
> constructor initializes the digest via a call that does not exist in 3.0, it
> breaks. The serialization logic is safe to use in both versions, but the
> object can't be constructed in 3.0.
> This fix directly instantiates the AvlTreeDigest, which exists in both
> versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
