[
https://issues.apache.org/jira/browse/FLINK-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962906#comment-16962906
]
Dawid Wysakowicz commented on FLINK-13702:
------------------------------------------
I had a look at this issue and I think the problem is not in the
{{BaseMapSerializer}} but in the {{LazyBinaryFormat}} class.
The method {{LazyBinaryFormat#ensureMaterialized}} is not thread safe.
Therefore e.g. when two threads call {{getSizeInBytes}}, the first one starts
materializing the {{BinaryString}} and sets the {{segments}} first, but before
it updates the {{sizeInBytes}} field the second thread calls {{getSizeInBytes}}
and assumes it has already been materialized (segments were set) so it just
returns the sizeInBytes value which is equal to {{-1}} as it was not yet
updated.
A potential solution to the problem would be to synchronize the
{{LazyBinaryFormat#ensureMaterialized}} method. Unfortunately, it has a
potential performance penalty. Do you think the {{BinaryFormat}} classes should
be thread safe? I think they should. Or were they supposed to work only in a
single threaded context? If it is the latter we need to update the
{{BaseMapSerializerTest.testDuplicate}} to perform a copy of the input item
before serializing it (in {{SerializerTestBase.SerializerRunner#run}}).
[~tzulitai] WDYT about the changes to the {{SerializerTestBase}}? Does it make
sense to add the copy anyways?
WDYT? [~lzljs3620320] [~jark]
> BaseMapSerializerTest.testDuplicate fails on Travis
> ---------------------------------------------------
>
> Key: FLINK-13702
> URL: https://issues.apache.org/jira/browse/FLINK-13702
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Planner
> Affects Versions: 1.10.0
> Reporter: Till Rohrmann
> Assignee: Dawid Wysakowicz
> Priority: Critical
> Labels: test-stability
>
> The {{BaseMapSerializerTest.testDuplicate}} fails on Travis with an
> {{java.lang.IndexOutOfBoundsException}}.
> https://api.travis-ci.org/v3/job/570973199/log.txt
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
