[
https://issues.apache.org/jira/browse/IGNITE-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov closed IGNITE-1899.
---------------------------------
> Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite
> nodes started in the same JVM
> --------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-1899
> URL: https://issues.apache.org/jira/browse/IGNITE-1899
> Project: Ignite
> Issue Type: Bug
> Components: general
> Reporter: Andrey Kornev
>
> The current approach to serialization/deserialization of {{IgniteKernal}} is
> flawed as it relies on the grid name. However, in a situation when a single
> JVM instance has multiple Ignite instances started (as is often the case in
> unit tests) this approach doesn't work. Ignite requires that each Ignite
> instance started within the same JVM be assigned different names. Thus,
> during deserialization on another node a wrong instance of {{IgniteKernal}}
> gets looked up.
> Say, the JVM instance has 2 nodes started: node A and node B. Then, when the
> node A serializes {{IgniteKernal}} it'll write the grid name "A" to the wire.
> Then, during deserialization of the {{IgniteKernal}} instance on the node B,
> the name "A" will be read from the wire and used to look up the Ignite
> instance uisng {{Ignition.ignite("A");}}. Clearly the class (holding a
> reference to {{IgniteKernal}}) ends up with a wrong instance of Ignite. If
> the class also retrieves the node-local resources by doing
> {{Ignition.ignite(deserializedGridName).cluster().nodeLocalMap()}} then it
> may end up with incorrect data.
> As of Ignite 1.4, {{ClusterGroupAdapter}} class or any other class that
> serialize the instance of {{IgniteKernal}} suffer from this issue. The fix
> would be to simply stop serializing the grid name altogether and during
> deserialization rely on the thread local instead, as per IGNITE-1898.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
