You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ignite.apache.org by Roman Shtykh <rs...@yahoo.com.INVALID> on 2019/01/17 04:37:23 UTC

CompactFooter for ClientBinaryMarshaller

Igniters,
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

Re: CompactFooter for ClientBinaryMarshaller

Posted by Ivan Pavlukhin <vo...@gmail.com>.

Both issues are related to "compact footer".

https://issues.apache.org/jira/browse/IGNITE-10960 is about comparison
equal objects with and without compact footer.
https://issues.apache.org/jira/browse/IGNITE-12003 is about binary
metadata retrieval by thin client for objects with compact footer.

I suppose both problems are present in 2.7.6 (and even in upcoming
2.8). The safest workaround so far is using compactFooter=false
everywhere.

Feel free to contribute a patch fixing any of the problems. Do not
hesitate to ask if you need any assistance.

пт, 31 янв. 2020 г. в 00:07, tschauenberg <ts...@invidi.com>:
>
> Igor, can you have a look at
> https://issues.apache.org/jira/browse/IGNITE-12003 and link it to
> https://issues.apache.org/jira/browse/IGNITE-10960?
>
> Using Java 2.7.0 thin client, Java 2.7.0 thick client and Java 2.7.0 Ignite
> servers I first hit IGNITE-10960 and then reading your comments and the
> proposed fix and this mailing list I tried to set the compact header in the
> thin client to true to match the thick client but then hit the bug from
> IGNITE-12003.
>
> We hope to upgrade to 2.7.6 as soon but until we do I can't confirm the
> behaviour is still a problem in 2.7.6.  I suspect it still is given
> IGNITE-12003 reports the bug in 2.7.5.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/



-- 
Best regards,
Ivan Pavlukhin

Re: CompactFooter for ClientBinaryMarshaller

Posted by tschauenberg <ts...@invidi.com>.

Igor, can you have a look at
https://issues.apache.org/jira/browse/IGNITE-12003 and link it to
https://issues.apache.org/jira/browse/IGNITE-10960?

Using Java 2.7.0 thin client, Java 2.7.0 thick client and Java 2.7.0 Ignite
servers I first hit IGNITE-10960 and then reading your comments and the
proposed fix and this mailing list I tried to set the compact header in the
thin client to true to match the thick client but then hit the bug from
IGNITE-12003.

We hope to upgrade to 2.7.6 as soon but until we do I can't confirm the
behaviour is still a problem in 2.7.6.  I suspect it still is given
IGNITE-12003 reports the bug in 2.7.5.  



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: CompactFooter for ClientBinaryMarshaller

Posted by Igor Sapego <is...@apache.org>.

Yeah, I was surprised too )

Best Regards,
Igor


On Wed, Jan 23, 2019 at 11:16 AM Vladimir Ozerov <vo...@gridgain.com>
wrote:

> It's hard to believe that compact footers are not supported, as it was one
> of critical performance optimizations we implemented more than 4 years ago
> :-)
> If it is really so, we should prioritize the fix.
>
> On Tue, Jan 22, 2019 at 3:28 PM Igor Sapego <is...@apache.org> wrote:
>
> > Roman,
> >
> > I've filed a ticket for C++: [1]
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-11027
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Jan 22, 2019 at 12:55 PM Roman Shtykh <rshtykh@yahoo.com.invalid
> >
> > wrote:
> >
> > > 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> wrote:
> > >
> > >  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> wrote:
> > >
> > >  "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 <is...@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.
> > >
> > > --
> > > Roman
> > >
> > >
> > >     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> > > isapego@apache.org> wrote:
> > >
> > >  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 compatibility.
> > > Best Regards,Igor
> > >
> > > On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rshtykh@yahoo.com.invalid
> >
> > > wrote:
> > >
> > > Igniters,
> > > 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
> > >
> > >
> > >
> > >
> > >
> >
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Vladimir Ozerov <vo...@gridgain.com>.

It's hard to believe that compact footers are not supported, as it was one
of critical performance optimizations we implemented more than 4 years ago
:-)
If it is really so, we should prioritize the fix.

On Tue, Jan 22, 2019 at 3:28 PM Igor Sapego <is...@apache.org> wrote:

> Roman,
>
> I've filed a ticket for C++: [1]
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-11027
>
> Best Regards,
> Igor
>
>
> On Tue, Jan 22, 2019 at 12:55 PM Roman Shtykh <rs...@yahoo.com.invalid>
> wrote:
>
> > 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> wrote:
> >
> >  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 <rs...@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> wrote:
> >
> >  "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 <is...@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 <rs...@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.
> >
> > --
> > Roman
> >
> >
> >     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> > isapego@apache.org> wrote:
> >
> >  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 compatibility.
> > Best Regards,Igor
> >
> > On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rs...@yahoo.com.invalid>
> > wrote:
> >
> > Igniters,
> > 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
> >
> >
> >
> >
> >
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Igor Sapego <is...@apache.org>.

Roman,

I've filed a ticket for C++: [1]

[1] - https://issues.apache.org/jira/browse/IGNITE-11027

Best Regards,
Igor


On Tue, Jan 22, 2019 at 12:55 PM Roman Shtykh <rs...@yahoo.com.invalid>
wrote:

> 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> wrote:
>
>  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 <rs...@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> wrote:
>
>  "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 <is...@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 <rs...@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.
>
> --
> Roman
>
>
>     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> isapego@apache.org> wrote:
>
>  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 compatibility.
> Best Regards,Igor
>
> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rs...@yahoo.com.invalid>
> wrote:
>
> Igniters,
> 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
>
>
>
>
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.

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 <is...@apache.org> wrote:

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 <rs...@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 <vo...@gridgain.com> wrote:

"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 <is...@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 <rs...@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.

--
Roman

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

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 compatibility.
Best Regards,Igor

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

Igniters,
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

Re: CompactFooter for ClientBinaryMarshaller

Posted by Igor Sapego <is...@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 compact
footers to true by default.

Best Regards,
Igor


On Sat, Jan 19, 2019 at 6:52 AM Roman Shtykh <rs...@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> wrote:
>
>  "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 <is...@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 <rs...@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.
>
> --
> Roman
>
>
>     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> isapego@apache.org> wrote:
>
>  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 compatibility.
> Best Regards,Igor
>
> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rs...@yahoo.com.invalid>
> wrote:
>
> Igniters,
> 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
>
>
>
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.

-- Roman
On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov <vo...@gridgain.com> 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 <rs...@yahoo.com.invalid> wrote:

--
Roman

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

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

-- Roman

Re: CompactFooter for ClientBinaryMarshaller

Posted by Vladimir Ozerov <vo...@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 <is...@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 <rs...@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.
>>
>> --
>> Roman
>>
>>
>>     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
>> isapego@apache.org> wrote:
>>
>>  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 compatibility.
>> Best Regards,
>> Igor
>>
>>
>> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rs...@yahoo.com.invalid>
>> wrote:
>>
>> Igniters,
>> 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
>>
>>
>
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Igor Sapego <is...@apache.org>.

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 <rs...@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.
>
> --
> Roman
>
>
>     On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <
> isapego@apache.org> wrote:
>
>  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 compatibility.
> Best Regards,
> Igor
>
>
> On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rs...@yahoo.com.invalid>
> wrote:
>
> Igniters,
> 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
>
>

Re: CompactFooter for ClientBinaryMarshaller

Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.

> 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.

--
Roman
 

    On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego <is...@apache.org> wrote:  
 
 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 compatibility.
Best Regards,Igor

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

Igniters,
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

Re: CompactFooter for ClientBinaryMarshaller

Posted by Igor Sapego <is...@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 with
backward compatibility.

Best Regards,
Igor


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

> Igniters,
> 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
>