ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Grid behavior at key deserialization failure during rebalancing
Date Tue, 16 Feb 2016 09:58:34 GMT
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.

D.

On Tue, Feb 16, 2016 at 12:37 AM, Anton Vinogradov <avinogradov@gridgain.com
> wrote:

> 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.
>
> On Mon, Feb 15, 2016 at 10:43 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > 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?
> >
> > Thanks,
> > D.
> >
> > On Mon, Feb 15, 2016 at 1:20 AM, Anton Vinogradov <
> > avinogradov@gridgain.com>
> > wrote:
> >
> > > 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.
> > >
> > >
> > > On Sat, Feb 13, 2016 at 3:44 AM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > I am not sure I fully grok the use case. Can you please explain why a
> > key
> > > > can be broken?
> > > >
> > > > D.
> > > >
> > > > On Fri, Feb 12, 2016 at 7:11 AM, Anton Vinogradov <
> > > > avinogradov@gridgain.com>
> > > > wrote:
> > > >
> > > > > 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?
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message