Thanks very much for figuring this out Pavel. I will work around it for now.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Pavel Tupitsyn <[email protected]>
Sent: Friday, June 9, 2017 1:47:19 AM
To: [email protected]
Subject: Re: Get by key only working on .net for certain long literal values

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]<mailto:[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) 
<[email protected]<mailto:[email protected]>> 
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(binaryTypes)
            {
                NameMapper = new BinaryBasicNameMapper { IsSimpleName = true }
            };



From: Pavel Tupitsyn [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, 8 June 2017 6:55 PM

To: [email protected]<mailto:[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]<mailto:[email protected]>> 
wrote:
Hi. Yes, I am on 2.0.
Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Pavel Tupitsyn <[email protected]<mailto:[email protected]>>
Sent: Thursday, June 8, 2017 12:26:41 AM
To: [email protected]<mailto:[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/BinaryIdentityResolver-is-gone-in-2-0-but-default-seems-to-have-a-problem-td13444.html
http://apache-ignite-users.70518.x6.nabble.com/UPDATED-BinaryIdentityResolver-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]<mailto:[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




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