[
https://issues.apache.org/jira/browse/KYLIN-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206842#comment-16206842
]
Shaofeng SHI commented on KYLIN-2926:
-------------------------------------
Hi Yu, good catch; Using ThreadLocal in the DataTypeSerializers is dangerous;
The assumption is the deserialized object will be serialized in sequence (like
in MR case), or is immutable. In the GTAggregateScanner, obviously, it doesn't
match the requirement for HLLC and RAW.
The ultimate solution is to fix this in each Serializer class, making the
deserialize() return a new object or an immutable object. Like what we already
do in TopNCounterSerializer. That will be clearer and easier for maintenance
int the future.
[[email protected]] what's your opinion?
> DumpMerger return incorrect results
> -----------------------------------
>
> Key: KYLIN-2926
> URL: https://issues.apache.org/jira/browse/KYLIN-2926
> Project: Kylin
> Issue Type: Bug
> Affects Versions: v2.0.0
> Reporter: fengYu
> Assignee: fengYu
> Attachments:
> 0001-KYLIN-2926-DumpMerger-return-incorrect-results-creat.patch
>
>
> I our scenario, a cube query will get wrong result once coprocessor need to
> spill to disk, Our version is 2.0.0 and I find the root cause is that in
> DumpMerger.enqueueFromDump
> because in DataTypeSerializer kylin use a ThreadLocal variable ‘current’, It
> leading to different elements in dumpCurrentValues share the same object, so
> next fill up measure values will change the existing values.
> the incorrect measures is HLLC and raw, which use current variable in
> deserialize.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
