You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by "Anton Vinogradov (JIRA)" <ji...@apache.org> on 2016/02/16 11:29:18 UTC

[jira] [Created] (IGNITE-2660) Correct Grid behavior at key deserialization failure during rebalancing

Anton Vinogradov created IGNITE-2660:
----------------------------------------

             Summary: 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


Problem explanation:

 Anton Vinogradov <av...@gridgain.com>
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 <av...@gridgain.com>
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 <av...@gridgain.com>
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)