Well, the quick work around would be to add at least one named field to the object. Meanwhile, we'll try to figure out the right way to fix it without breaking backward compatibility.
Best Regards, Igor On Wed, Jul 31, 2024 at 10:46 AM Louis C <l...@outlook.fr> wrote: > Hello, > > Thanks for your answers. Igor, indeed I only use the raw reader/writer to > serialize my object. It indeed seems like the Java client thinks there is a > schema, even if this is fully raw. > > Pavel, find attached a repro code. There are the C++, Java and the conf I > used. > The C++ client first puts a value, then gets it. Then it uses a Java task > (TestTask) to add a particular value on the same key in the cache. When we > get back this value, this is still the initial value. > Then the C++ client calls the "ListCountersTask" that list all the keys in > the cache. As we can see there are 2 keys in the cache, that deserialize to > the same object, but have different binary representation. > See the capture: > Hope you'll manage to run the example. > > Regards > Louis > ------------------------------ > *De :* Pavel Tupitsyn <ptupit...@apache.org> > *Envoyé :* mardi 30 juillet 2024 11:16 > *À :* user@ignite.apache.org <user@ignite.apache.org> > *Objet :* Re: Ignite cache with custom key : key not found > > Louis, we need to see the code to help you - could you please share it, > both Java and C++ parts? Ideally a reproducer that we can run. > > On Tue, Jul 30, 2024 at 11:59 AM Igor Sapego <isap...@apache.org> wrote: > > What I see from the object is that it's fully raw, meaning, all the fields > written without names. Is that correct? > > In this case, there is no schema on C++ side, because there are no named > fields and schema is not needed. > Java client writes schemaInitialId() in this case, which is > FNV1_OFFSET_BASIS(0x811C9DC5). > > Looks like a bug in Java client to me. Pavel, what do you think? > > Best Regards, > Igor > > > On Tue, Jul 30, 2024 at 10:03 AM Louis C <l...@outlook.fr> wrote: > > Sorry to up this subject, but I have not been able to find a > solution/reason for this problem. > Does anyone have an idea ? > > Thanks, > > Louis C. > ------------------------------ > *De :* Louis C <l...@outlook.fr> > *Envoyé :* lundi 22 juillet 2024 17:06 > *À :* user@ignite.apache.org <user@ignite.apache.org> > *Objet :* RE: Ignite cache with custom key : key not found > > Hello, > > Thanks for your answers. > > As for the "compactFooter" I already set it to "false" in the xml config > of the server. For the client, it is the C++ thin client and in the > object"IgniteClientConfiguration" I can not do it, it seems. I believe > there is no need to set this parameter for the C++ thin client. > > It will be quite hard to extract a reproducible example, but I might do it > if necessary. > In the meantime I managed to extract the binary representartion of the 2 > differents keys (in hexadecimal) : > Key from C++ thin client : > 67 01 05 00 91 D3 05 6C 87 E6 CF 1E 26 00 00 00 00 00 00 00 18 00 00 00 05 > 00 00 00 0C 05 00 00 00 32 32 32 32 32 > Key from Java : > 67 01 05 00 91 D3 05 6C 87 E6 CF 1E 26 00 00 00 C5 9D 1C 81 18 00 00 00 05 > 00 00 00 0C 05 00 00 00 32 32 32 32 32 > > As we can see, the difference is the 4 bytes in position 17 to 20, > corresponding, if we follow > https://cwiki.apache.org/confluence/display/IGNITE/Binary%20object%20format to > the "Schema Id" which is a "has of the object fields". > In case of C++ thin client it is "00 00 00 00", and "C5 9D 1C 81". > The bytes in position 3 to 4 are " 05 00" which seems to indicate user > type + raw data, but indeed there is not the flag "compact footer" (0x20). > So it seems to be OK. > > I do not know if I said it but I add keys with a CacheEntryProcessor on > the java side of things. > Anyone has an idea ? > > Best regards, > Louis C. > > ------------------------------ > *De :* Николай Ижиков <nizhikov....@gmail.com> de la part de Nikolay > Izhikov <nizhi...@apache.org> > *Envoyé :* lundi 22 juillet 2024 10:33 > *À :* user@ignite.apache.org <user@ignite.apache.org> > *Objet :* Re: Ignite cache with custom key : key not found > > Hello. > > It common issue with the thin client. > Please, set same value of BinaryConfiguration#compactFooter explicitly to > false both on the server side and client side. > > On 22 Jul 2024, at 10:32, Pavel Tupitsyn <ptupit...@apache.org> wrote: > > Hello, could you please attach a reproducer? > > This might have to do with type names / ids mismatch, but hard to tell > without the code. > > On Fri, Jul 19, 2024 at 7:39 PM Louis C <l...@outlook.fr> wrote: > > Hello, > > I have a strange problem for which I can't find the reason. > > I made a cache (key/value cache) with a custom key type that is called > "IgniteBinaryData". > > I have a C++ thin client that calls the server and execute a Java > ComputeTaskAdapter<CustomType1,CustomType2> that I made (let's call it > "Task1"). > This Task1 writes data in the cache with the custom key type > "IgniteBinaryData". > > But the issue is that when I request the same cache from the C++ thin > client, the key is not found. > > What is strange is that I can then add the key with a "Put" from the C++, > and when I look at the deserialized keys in the java code, there does not > seem to be any difference between the 2 "different" keys, which are both > present in the cache. > > What I saw is that when I do a "Get" from the C++, the key is not > deserialized (Ignite looks only at the serialized data of the keys). > > So I think there might be a difference in the serialization of the key > between the Java code and the C++, but not visible when deserialized. > > But looking at all the entries in the cache with an iterator, I found no > differences. I tried using the".withKeepBinary();" method to access the > keys without deserialization, but I can't find a way to get the "bytes[]" > corresponding to the key from the BinaryObject. > > So, my question would be : how to get the "bytes[]" corresponding to a > custom key ? > And also, is there a known issue that could arise when doing this ? I > carefully followed > https://ignite.apache.org/docs/latest/cpp-specific/cpp-platform-interoperability > and > I have no problem of deserialization... > > Best regards, > > Louis C. > > >
