[
https://issues.apache.org/jira/browse/IGNITE-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-2660:
-------------------------------------
Priority: Minor (was: Major)
> Correct Grid behavior at key deserialization failure during rebalancing
> -----------------------------------------------------------------------
>
> Key: IGNITE-2660
> URL: https://issues.apache.org/jira/browse/IGNITE-2660
> Project: Ignite
> Issue Type: Task
> Affects Versions: 1.5.0.final
> Reporter: Anton Vinogradov
> Priority: Minor
>
> Problem explanation:
> Anton Vinogradov <[email protected]>
> Igniters,
> At this moment key deserialization failure during rebalancing cause strange
> situation:
> Rebalancing from node sent supply message with broken key will be cancelled
> at current topology.
> All upcoming supply messages from this node will be be ignored, no new demand
> messages to this node will be sent.
> But when topology will be changed again, node with broken key will take path
> at rebalancing again, untill key deserialization failure happen ... again.
> Do we need to improve this situation, and if we have to how should be handled
> case with key deserialization failure?
> I see some ways:
> 1) We can inform user about data loss because of deserialization problems,
> but keep current rebalancing strategy
> 2) We can continue rebalancing from this node, but ignore messages with
> broken keys. And inform user about data loss.
> 3) We can pause rebalancing untill deserialization will be fixed somehow, for
> example by shutdowning demanding or supplying node.
> Thoughts?
> Dmitriy Setrakyan
> Anton,
> I am not sure I fully grok the use case. Can you please explain why a key
> can be broken?
> Anton Vinogradov <[email protected]>
> Dmitriy,
> Key can be undeserializable during rebalancing because of many reasons.
> For example,
> 1) It was serialized with errors
> 2) Deserialization cause error
> 3) It based on classes unavailable at node trying to deserialize it
> Third is the most possible case.
> Dmitriy Setrakyan
> Anton,
> I am not sure why we would deserialize on the server side with Binary
> Marshaller. The data should remain in binary form. Do you know if we have a
> test for it?
> Anton Vinogradov <[email protected]>
> Dmitry,
> I found such behavior at GridCacheRebalancingUnmarshallingFailedSelfTest.
> Seems we always unmarshalling keys at supply message handling in case of
> OptimizeMarshaller used.
> Also it happens when BinaryMarshaller used but key class implements
> Externalizable.
> Dmitriy Setrakyan
> Anton,
> If there is no deserialization for binary marshaller, then I would treat it
> as a low priority issue. We should file a ticket and get to it when it
> becomes more critical.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
