[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1903:
----------------------------------------
Description:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{code}SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
{code}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
---
*UPDATE (copy-paste from comment below)*
This is actually more generic issue. When a new node joins (client or server),
all existing cache configurations (which include cache stores) are sent to this
node. It then deserializes it during startup which can cause exceptions on
clients or servers where cache is not supposed to be deployed as defined by
node filter.
As a solution we can do the following:
* During discovery, send node filter and cache store factory in binary format
along with the cache configuration, not as its parts.
* On server, check node filter first and deserialize cache configuration and
cache store only if it returns true. In case of error, STOP join process (now
we just print exception in log and go on, which is very error-prone).
* On client, do not deserialize cache configuration and cache store until
user's code tries to actually use the cache (calls Ignite.cache. If cache is
ATOMIC, never deserialize the cache store.
was:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{code}SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
{code}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
> CacheStore implementation is serialized to nodes whether they require it or
> not
> -------------------------------------------------------------------------------
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 1.5.0.final
> Reporter: Michael Griggs
> Labels: community
> Fix For: 2.0
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
