Found the bug: https://issues.apache.org/jira/browse/IGNITE-5455
Hash code calculation is inconsistent in Java and .NET.

Which means that cache keys of user-defined types can't be used when both
.NET and Java are involved.
The only workaround is to use basic type as a key (all primitives, string,
Guid, decimal).

This will be fixed shortly in master and released in 2.1, which should come
out this month.






On Thu, Jun 8, 2017 at 5:15 PM, Pavel Tupitsyn <[email protected]> wrote:

> Gordon, I have reproduced the issue.
> I will investigate it and get back to you later.
>
> Pavel
>
> On Thu, Jun 8, 2017 at 2:46 PM, Gordon Reid (Nine Mile) <gordon.reid@
> ninemilefinancial.com> wrote:
>
>> Thanks Pavel.
>>
>>
>>
>> The objects are loaded on the Java side, which is the server node.
>> Reading from Java client node works fine always. But reading from .net
>> client gives the problem mentioned.
>>
>>
>>
>> Yes, BinaryIdMapper and BinaryNameMapper are configured as per the wiki.
>>
>>
>>
>> Java side
>>
>>             BinaryConfiguration bcfg = new BinaryConfiguration();
>>
>>             bcfg.setCompactFooter(true);
>>
>>             bcfg.setIdMapper(new BinaryBasicIdMapper(true));
>>
>>             bcfg.setNameMapper(new BinaryBasicNameMapper(true));
>>
>>             icfg.setBinaryConfiguration(bcfg);
>>
>>
>>
>> .NET side
>>
>>             var binaryTypes = new []
>>
>>             {
>>
>>                 ....
>>
>>                 typeof(SecurityKey),
>>
>>                 typeof(Security),
>>
>>                 ....
>>
>>                 }
>>
>>
>>
>>
>>
>>             cfg.BinaryConfiguration = new BinaryConfiguration(binaryType
>> s)
>>
>>             {
>>
>>                 NameMapper = new BinaryBasicNameMapper { IsSimpleName =
>> true }
>>
>>             };
>>
>>
>>
>>
>>
>>
>>
>> *From:* Pavel Tupitsyn [mailto:[email protected]]
>> *Sent:* Thursday, 8 June 2017 6:55 PM
>>
>> *To:* [email protected]
>> *Subject:* Re: Get by key only working on .net for certain long literal
>> values
>>
>>
>>
>> I've tried to use your class as a cache key and it seems to work, see
>> attached program.
>>
>>
>>
>> * How do you add these objects to cache? Is it from Java or .NET?
>>
>> * Have you configured BinaryIdMapper on .NET and Java sides properly so
>> that classes map to each other?
>>
>>
>>
>> Pavel
>>
>>
>>
>> On Thu, Jun 8, 2017 at 12:07 AM, Gordon Reid (Nine Mile) <
>> [email protected]> wrote:
>>
>> Hi. Yes, I am on 2.0.
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>>
>> ------------------------------
>>
>> *From:* Pavel Tupitsyn <[email protected]>
>> *Sent:* Thursday, June 8, 2017 12:26:41 AM
>> *To:* [email protected]
>> *Subject:* Re: Get by key only working on .net for certain long literal
>> values
>>
>>
>>
>> Hi Gordon,
>>
>>
>>
>> Seems like all your threads are related:
>>
>> http://apache-ignite-users.70518.x6.nabble.com/BinaryIdentit
>> yResolver-is-gone-in-2-0-but-default-seems-to-have-a-problem-td13444.html
>>
>> http://apache-ignite-users.70518.x6.nabble.com/UPDATED-Binar
>> yIdentityResolver-is-gone-in-2-0-but-default-seems-to-have-
>> a-problem-td13445.html
>>
>>
>>
>> Let's discuss them here.
>>
>>
>>
>> First of all, can you confirm that you are on Ignite 2.0?
>>
>>
>>
>> Pavel
>>
>>
>>
>> On Wed, Jun 7, 2017 at 11:03 AM, Gordon Reid (Nine Mile) <
>> [email protected]> wrote:
>>
>> Hi There,
>>
>>
>>
>> This one is very strange.
>>
>>
>>
>> I have a .NET client, Java client and Java server. All running locally on
>> windows desktop.
>>
>>
>>
>> On the server side I have some cache entries, SecurityKey,Security
>>
>>
>>
>> I have two Security objects, one with id=4 and one with id=953
>>
>>
>>
>> On the Java client, this works no problem
>>
>>
>>
>> SystemContext.getCache().get(new SecurityKey(4));
>>
>> SystemContext.getCache().get(new SecurityKey(953));
>>
>>
>>
>>
>>
>> On the .NET client
>>
>>
>>
>> (Security)SystemContext.Cache.Get(new SecurityKey() { Id = 4 });
>>
>>
>>
>> Will succeed
>>
>>
>>
>> (Security)SystemContext.Cache.Get(new SecurityKey() { Id = 953 });
>>
>>
>>
>> Will FAIL, with KeyNotFoundException
>>
>>
>>
>> This is the case 100% of the time, even after full restart of the
>> environment. The only thing that seems to cause the problem is the literal
>> value of the id
>>
>>
>>
>> Also note that if I iterate over the cache on the .NET side, I can
>> absolutely see the SecurityKey with id=953, but I will see KeyNotFound when
>> I try to Get
>>
>>
>>
>>             foreach (var e in SystemContext.Cache)
>>
>>             {
>>
>>                 if (e.Key is SecurityKey)
>>
>>                 {
>>
>>                     Log.Info(((SecurityKey)e.Key).Id); // this will
>> print both 4 and 953
>>
>>                 }
>>
>>             }
>>
>>
>>
>> My only guess here is that something funny is going on internally with
>> the hashing of the binary object fields. So the equality test is failing
>> when the get is done from the .NET client??
>>
>>
>>
>> I have attached the key class as it is on the .NET side and the Java side.
>>
>>
>>
>> Any thoughts are much appreciated. Thanks!
>>
>>
>>
>>
>>
>> This email and any attachments are proprietary & confidential and are
>> intended solely for the use of the individuals to whom it is addressed. Any
>> views or opinions expressed are solely for those of the author and do not
>> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
>> received this email in error, please let us know immediately by reply email
>> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
>> 1349 0252
>>
>>
>>
>>
>>
>>
>>
>> This email and any attachments are proprietary & confidential and are
>> intended solely for the use of the individuals to whom it is addressed. Any
>> views or opinions expressed are solely for those of the author and do not
>> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
>> received this email in error, please let us know immediately by reply email
>> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
>> 1349 0252
>>
>>
>>
>>
>>
>>
>>
>> This email and any attachments are proprietary & confidential and are
>> intended solely for the use of the individuals to whom it is addressed. Any
>> views or opinions expressed are solely for those of the author and do not
>> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
>> received this email in error, please let us know immediately by reply email
>> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
>> 1349 0252
>>
>
>

Reply via email to