Reputation: 73
My goal is to run a Java Ignite node with a .NET client connecting to it. As I've been having some issues I've gone to an even simpler example of not a server/client model but a server/server model. Prior to Ignite 2.0 you could set up a BinaryConfiguration on the Java side like so:
// Configure Ignite to connect with .NET nodes
BinaryConfiguration binCfg = new BinaryConfiguration();
binCfg.setIdMapper(new BinaryBasicIdMapper());
binCfg.setNameMapper(new BinaryBasicNameMapper());
This works in the sample projects shown here: https://ptupitsyn.github.io/Ignite-Multi-Platform-Cluster/
However, if you take these two working projects and upgrade them from Ignite 1.7.0 to Ignite 2.0.0, you'll now get the following exception (this is from the Java side):
Caused by: class org.apache.ignite.spi.IgniteSpiException: Local node's binary configuration is not equal to remote node's binary configuration [locNodeId=2d98d083-859f-4bae-bb9a-16fe00f9f39a, rmtNodeId=d9f68030-79b1-4e41-bd00-1bec44dca9e3, locBinaryCfg={globIdMapper=org.apache.ignite.binary.BinaryBasicIdMapper, compactFooter=true, globSerializer=null}, rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
You'll notice that in the above exception that the Java node has the BinaryBasicIdMapper setup, however the remote .NET node does not have this mapper anymore, which is causing this exception.
I've tried the following to no avail:
I've been scouring the Ignite docs trying to figure out what to do in Ignite 2.0, but I can't find any examples of what to do. Has anyone else faced this issue? How did you resolve it?
Upvotes: 1
Views: 436
Reputation: 8986
To join Java and .NET nodes in Ignite 2.0+ and map types to each other:
BinaryBasicNameMapper
with SimpleName
on both sidesIdMapper
ignite.binary().type(Foo.class)
(Java) and ignite.GetBinary().GetBinaryType(typeof(Foo))
(.NET)Details:
Ignite.NET 2.0+ employs the same dynamic type registration as Java had before. No need to register types in BinaryConfiguration before starting the node. Normally, you would not need to bother about registering the types at all (like we did with GetBinaryType call) - type is registered automatically on first usage. However, when more than one platform is involved, you can get this "unknown pair" exception, because each platform registers the type in a separate data structure. Why? Because on deserialization Ignite needs to instantiate an actual class. In .NET this class may be Foo.Bar.Message
, in Java org.foo.bar.Message
. So even though both these classes map to the same Ignite binary type (simple name mapper throws away namespace/package), on deserialization we need to know fully-qualified name.
I've updated the blog post in question and added working example to ignite-2.0 branch
Upvotes: 1