ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Reid (Nine Mile)" <gordon.r...@ninemilefinancial.com>
Subject Re: Get by key only working on .net for certain long literal values
Date Thu, 08 Jun 2017 20:33:58 GMT
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 <ptupitsyn@apache.org>
Sent: Friday, June 9, 2017 1:47:19 AM
To: user@ignite.apache.org
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 <ptupitsyn@apache.org<mailto:ptupitsyn@apache.org>>
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<mailto: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(binaryTypes)
            {
                NameMapper = new BinaryBasicNameMapper { IsSimpleName = true }
            };



From: Pavel Tupitsyn [mailto:ptupitsyn@apache.org<mailto:ptupitsyn@apache.org>]
Sent: Thursday, 8 June 2017 6:55 PM

To: user@ignite.apache.org<mailto:user@ignite.apache.org>
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) <gordon.reid@ninemilefinancial.com<mailto:gordon.reid@ninemilefinancial.com>>
wrote:
Hi. Yes, I am on 2.0.
Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Pavel Tupitsyn <ptupitsyn@apache.org<mailto:ptupitsyn@apache.org>>
Sent: Thursday, June 8, 2017 12:26:41 AM
To: user@ignite.apache.org<mailto:user@ignite.apache.org>
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) <gordon.reid@ninemilefinancial.com<mailto:gordon.reid@ninemilefinancial.com>>
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

Mime
View raw message