ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shtykh <rsht...@yahoo.com.INVALID>
Subject Re: CompactFooter for ClientBinaryMarshaller
Date Tue, 22 Jan 2019 09:55:36 GMT
Igor, I see. How about having a warning if `BinaryConfiguration` is not provided explicitly
to at least raise attention? And creating a JIRA issue for C++ clients -- after it resolves
we can probably switch it to cluster default.

Roman Shtykh 

    On Monday, January 21, 2019, 7:04:30 p.m. GMT+9, Igor Sapego <isapego@apache.org>
 I believe, it was set to false by default as it was kind of experimental optimisation.
Also, I've checked right now and it seems that C++ clients (thick and thin)do not yet support
compact footers. It may also be a blocker to set compactfooters to true by default.
Best Regards,Igor

On Sat, Jan 19, 2019 at 6:52 AM Roman Shtykh <rshtykh@yahoo.com.invalid> wrote:

Thank you for the explanation. But here is the problem is not exactly with deserialization
but with that a user-defined key is being marshalled to a binary object with the compact footer
set to true, while the key for putting has the footer set to false (which is server default).
Thus we have a different thing for the key when we try to retrieve and getting null.
Therefore, I suppose switching client to server defaults is what has to be done. If the user
decides to switch to full schema mode, at least he/she will be aware of it. And for deserialization,
the schema will be retrieved, as you explained. What do you think?

-- Roman
    On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov <vozerov@gridgain.com>

 "Compact footer" is optimization which saves a lot of space. Object serialized in this form
do not have the full information required for deserialization. Metadata necessary for deserialization
(aka "schema") is located on cluster nodes. For this client it could be requested through
special command. Pleass see ClientOperation.GET_BINARY_TYPE as a starting point.
On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego <isapego@apache.org> wrote:

I'm not sure, that such a change should be done in minor release, maybe in 3.0
Vova, what do you think? It was you, who designed and developed compact footer, right?
Best Regards,Igor

On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh <rshtykh@yahoo.com.invalid> wrote:

> I believe it has something to do with backward compatibility.That's what I would like
to know.If there's no strong reason to set it to false, it should be as Ignite's default --
that's what a user would expect. And if the user changes the configuration at the cluster,
he/she will be aware of that and change it at thin client.If we cannot set it to Ignite's
default, we can add a log message saying we force it to false.


    On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <isapego@apache.org>

 First of all, I do not like that thin client is silently returns null. It should be fixed.
For the compact footer being set to false by default - I believe it has something to do withbackward
Best Regards,Igor

On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rshtykh@yahoo.com.invalid> wrote:

After putting some data with a user-defined key with a thick client, it's impossible to retrieve
it with a thin client.https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it
was a bug, so I first reported the issue to the user ml, Mikhail thanks for checking and the
jira issue)
That happens because for Ignite `compactFooter` is `true` by default, but `ClientBinaryMarshaller`
forces it to `false` if `BinaryConfiguration` is not created explicitly (see ClientBinaryMarshaller#createImpl).
Any reason to force it to false? I would like to align it with Ignite defaults (by setting
to true).

-- Roman


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