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.
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
Yeah, I was surprised too )
Best Regards,
Igor
On Wed, Jan 23, 2019 at 11:16 AM Vladimir Ozerov
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
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 wrote:
> Roman,
>
> I've filed a ticket for
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
wrote:
> Igor, I see. How about having a warning if `BinaryConfiguration` is not
> provided explicitly to at least raise
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.
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,
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
"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
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
wrote:
> > I believe it has something to do with backward
> 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
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
wrote:
> Igniters,
>
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
13 matches
Mail list logo
