ClassNotFoundException on recieving end of replication

[garentsen]

Hi,

I've defined an MBean as a TreeCache and deployed to 5 servers in the same cluster. The find each other and I can see from the log that everything seems fine.

Inserting Strings in the cache works fine, they are replicated to all servers.

However, when inserting a class of my own type I get this in the receiving ends:

16:07:58,834 ERROR [RpcDispatcher]
exception=java.lang.IllegalArgumentException:
java.lang.ClassNotFoundException: No ClassLoaders found for:
se.bonnier.bis.applications.testapp.SimplePojo

And the object is not placed in the recievers cache. It can still be found in the cache from where it was placed though.

It was my understanding that replicated objects are serialized pre sending them and then deserialized to Object by the reciever. Am I wrong or should this not cause a ClassNotFoundException?

The application from which the MBean is deployed may not have access to all classes available to other deployed applications on the server, and therefore I find it strange that a distributed caching system cannot handle classes of unknown types to the current classloader.

Is there a workaround I can use, have I missunderstood the whole concept of the cache or can someone point me in the right direction towards a solution?

Thanks in advance

/Emil

Here is my MBean def:

<mbean code="org.jboss.cache.TreeCache"
 name="jboss.cache:service=BisinfraCache">

 <depends>jboss:service=Naming</depends>
 <depends>jboss:service=TransactionManager</depends>


 <!-- Configure the TransactionManager
 <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
-->
 <!--
 Node locking level : SERIALIZABLE
 REPEATABLE_READ (default)
 READ_COMMITTED
 READ_UNCOMMITTED
 NONE
 -->
 <attribute name="IsolationLevel">REPEATABLE_READ</attribute>

 <!-- Valid modes are LOCAL
 REPL_ASYNC
 REPL_SYNC
 -->
 <attribute name="CacheMode">REPL_ASYNC</attribute>

 <!-- Name of cluster. Needs to be the same for all clusters, in order
 to find each other -->
 <attribute name="ClusterName">bisinfra-application-cache-cluster</attribute>

 <attribute name="ClusterConfig">
 <config>
 <!-- UDP: if you have a multihomed machine,
 set the bind_addr attribute to the appropriate NIC IP address
 -->
 <!-- UDP: On Windows machines, because of the media sense feature
 being broken with multicast (even after disabling media sense)
 set the loopback attribute to true
 -->
 <UDP mcast_addr="228.1.2.3" mcast_port="45566" ip_ttl="64" ip_mcast="true"
 mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000"
 ucast_recv_buf_size="80000" loopback="true" />
 <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" />
 <MERGE2 min_interval="10000" max_interval="20000" />
 <FD shun="true" up_thread="true" down_thread="true" />
 <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
 <pbcast.NAKACK gc_lag="50" max_xmit_size="8192" retransmit_timeout="600,1200,2400,4800" up_thread="false"
 down_thread="false" />
 <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" />
 <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
 <FRAG frag_size="8192" down_thread="false" up_thread="false" />
 <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
 <pbcast.STATE_TRANSFER up_thread="false" down_thread="false" />
 </config>
 </attribute>

 <!-- The max amount of time (in milliseconds) we wait until the
 initial state (ie. the contents of the cache) are retrieved from
 existing members in a clustered environment
 -->
 <attribute name="InitialStateRetrievalTimeout">5000</attribute>

 <!-- Number of milliseconds to wait until all responses for a
 synchronous call have been received.
 -->
 <attribute name="SyncReplTimeout">10000</attribute>

 <!-- Max number of milliseconds to wait for a lock acquisition -->
 <attribute name="LockAcquisitionTimeout">15000</attribute>

 <!-- Name of the eviction policy class. -->
 <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>

 <!-- Specific eviction policy configurations. This is LRU -->
 <attribute name="EvictionPolicyConfig">
 <config>
 <attribute name="wakeUpIntervalSeconds">5</attribute>
 <!-- Cache wide default -->
 <region name="/_default_">
 <attribute name="maxNodes">5000</attribute>
 <attribute name="timeToLiveSeconds">1800</attribute>
 </region>

 <!-- place transferIds in this branch valid for 30s only -->
 <region name="/security">
 <attribute name="maxNodes">5000</attribute>
 <attribute name="timeToLiveSeconds">30</attribute>
 </region>

 <!-- Default branch for bisinfra cached objects,
 valid for 45 minutes -->
 <region name="/bisinfra">
 <attribute name="maxNodes">5000</attribute>
 <attribute name="timeToLiveSeconds">2700</attribute>
 </region>

 <!-- Default branch for bisinfra sessions,
 valid for 30 minutes -->
 <region name="/sessions">
 <attribute name="maxNodes">5000</attribute>
 <attribute name="timeToLiveSeconds">1800</attribute>
 </region>
 </config>
 </attribute>

</mbean>

[garentsen]

Hi again,

I now understand why this happens. Since updates are per field values and not whole objects this is the way it must be.

Important classes must be placed in global classpath or make sure one uses only the standard set of classes.

[brian.stansberry]

In JBossCache 1.2.4 we are introducing an API to allow applications register their classloader for use in deserializing replication events for a portion of the cache.

The basic API is

public void registerClassLoader(String fqn, ClassLoader cl)

public void unregisterClassLoader(String fqn)

To use this, when you configure your cache you have to set config property UseMarshalling to true -- this can be done programatically via a setter or as an attribute in the XML config file.

There are a number of other subtleties related to this, too much to explain here. A prelim version of this is in the released 1.2.4 Beta, but I've made a number of improvements since then, plus the docs are not in the beta.