Binary marshaller issues

[Valentin Kulichenko]

Folks,

Based on user's feedback about beta of 1.5, I created several tickets for
binary marshaller that should be fixed in the final version. Here is the
list:

   - https://issues.apache.org/jira/browse/IGNITE-2098
   - https://issues.apache.org/jira/browse/IGNITE-2099
   - https://issues.apache.org/jira/browse/IGNITE-2100

First two look trivial.

As for the IGNITE-2100, I would like to ask community to take a look at it
and share thoughts on how this should be fixed.

-Val

[Alexey Goncharuk]

While checking the Proxy test, I discovered another issue with
BinaryMarshaller:
https://issues.apache.org/jira/browse/IGNITE-2104

Even though it is not as critical as the other three mentioned by Val, it
would be nice to get it fixed in 1.5-GA.

[Vladimir Ozerov]

Valya,

Regarding *IGNITE-2100*. For now in case of Externalizable class we
delegate to OptimizedMarshaller, which is more or less fine I think.

Several solutions possible:

1) In case an attempt to read a field of such object is performed, we can
throw an exception with workaround in message. Workarounds could be:

   - Implement Binarizable interface for this class. Problem: sometimes
   user cannot change class.
   - Introducee BinarySerializer for this type and add it to configuration.
   Problem: boilerplate code, public field getters are required.


2) Deserialize such object and use reflection to get field. This is the
most user-friendly solution, but will require more time due to changes in
cache/query logic.

Thoughts?

Vladimir.


On Tue, Dec 8, 2015 at 1:50 PM, Alexey Goncharuk <[hidden email]
> wrote:

> While checking the Proxy test, I discovered another issue with
> BinaryMarshaller:
> https://issues.apache.org/jira/browse/IGNITE-2104
>
> Even though it is not as critical as the other three mentioned by Val, it
> would be nice to get it fixed in 1.5-GA.
>

[Alexey Goncharuk]

Vova,

We still have the logic that allows us to use reflection to get values in
indexing, so basically the change is an additional check during the query
processor start.

My concern regarding (2) is that a server node must have model classes in
the classpath in order to check that we should deserialize values for
indexing. If a server node does not have classes in the classpath and user
still uses Externalizable classes on client, we will still end up with the
same situation and it looks like we will not be able to detect it. Is there
a way to tell that an object was externalizable without the class on server
node?

[Vladimir Ozerov]

Alex,

I was wrong about OptimizedMarshaller. We handle Externalizable a bit
differently: we immediately swtich to "raw mode" and write object's content
in raw form. This situation can be detected using several flags in object
header. But the same flags will be set if user implemented Binarizable and
manually switched object to raw mode. So the answer is no - we cannot
detected this situation reliably at the moment.

May be some new flag could help us. It could mean "cannot read fields from
deserialized object".

On Tue, Dec 8, 2015 at 3:03 PM, Alexey Goncharuk <[hidden email]
> wrote:

> Vova,
>
> We still have the logic that allows us to use reflection to get values in
> indexing, so basically the change is an additional check during the query
> processor start.
>
> My concern regarding (2) is that a server node must have model classes in
> the classpath in order to check that we should deserialize values for
> indexing. If a server node does not have classes in the classpath and user
> still uses Externalizable classes on client, we will still end up with the
> same situation and it looks like we will not be able to detect it. Is there
> a way to tell that an object was externalizable without the class on server
> node?
>

[dsetrakyan]

My preference would be to deserialize and grab the fields using reflection,
assuming the class is available on the server. If the class is not
available, then a corresponding field-access operation should produce an
exception with a proper error message, instructing user how to address it.

There is no need to punish users with some idealistic unsupported
exceptions if the classes are available on the server side.

D.

On Tue, Dec 8, 2015 at 4:16 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Alex,
>
> I was wrong about OptimizedMarshaller. We handle Externalizable a bit
> differently: we immediately swtich to "raw mode" and write object's content
> in raw form. This situation can be detected using several flags in object
> header. But the same flags will be set if user implemented Binarizable and
> manually switched object to raw mode. So the answer is no - we cannot
> detected this situation reliably at the moment.
>
> May be some new flag could help us. It could mean "cannot read fields from
> deserialized object".
>
> On Tue, Dec 8, 2015 at 3:03 PM, Alexey Goncharuk <
> [hidden email]
> > wrote:
>
> > Vova,
> >
> > We still have the logic that allows us to use reflection to get values in
> > indexing, so basically the change is an additional check during the query
> > processor start.
> >
> > My concern regarding (2) is that a server node must have model classes in
> > the classpath in order to check that we should deserialize values for
> > indexing. If a server node does not have classes in the classpath and
> user
> > still uses Externalizable classes on client, we will still end up with
> the
> > same situation and it looks like we will not be able to detect it. Is
> there
> > a way to tell that an object was externalizable without the class on
> server
> > node?
> >
>