Hi, We were using JBoss Cache 1.2.3 in our web application run on Tomcat server. Recently we decided to upgrade to JBoss Cache 1.4.1. For this the following changes were made. -- Added jboss-cache-jdk50.jar (instead of jboss-cache.jar) -- jboss-aop-jdk50.jar (instead of jboss-aop.jar) -- jboss-serialization.jar The following is the configuration xml used. <?xml version="1.0" encoding="UTF-8" ?> | <server> | | <!-- ==================================================================== --> | <!-- Defines TreeCache configuration --> | <!-- ==================================================================== --> | <!-- | <mbean code="org.jboss.cache.aop.TreeCacheAop" | name="jboss.cache:service=TreeCacheAop"> --> | <mbean code="org.jboss.cache.aop.PojoCache" | name="jboss.cache:service=PojoCache"> | <depends>jboss:service=TransactionManager</depends> | <!-- Configure the TransactionManager --> | <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute> | | <!-- | Node locking scheme : | PESSIMISTIC (default) | OPTIMISTIC | --> | <attribute name="NodeLockingScheme">OPTIMISTIC</attribute> | | <!-- | Node locking isolation level : | SERIALIZABLE | REPEATABLE_READ (default) | READ_COMMITTED | READ_UNCOMMITTED | NONE | | (ignored if NodeLockingScheme is OPTIMISTIC) | --> | <attribute name="IsolationLevel">REPEATABLE_READ</attribute> | | <!-- Lock parent before doing node additions/removes | Only for PESSIMISTIC Locking--> | <attribute name="LockParentForChildInsertRemove">true</attribute> | | <!-- Valid modes are LOCAL | REPL_ASYNC | REPL_SYNC | INVALIDATION_ASYNC | INVALIDATION_SYNC | --> | <attribute name="CacheMode">LOCAL</attribute> | | <!-- Whether each interceptor should have an mbean | registered to capture and display its statistics. --> | <attribute name="UseInterceptorMbeans">true</attribute> | | <!-- Name of cluster. Needs to be the same for all TreeCache nodes in a | cluster, in order to find each other --> | <attribute name="ClusterName">JBoss-Cache-Cluster</attribute> | | <!-- Uncomment next three statements to enable JGroups multiplexer. | This configuration is dependent on the JGroups multiplexer being | registered in an MBean server such as JBossAS. --> | <!-- | <depends>jgroups.mux:name=Multiplexer</depends> | <attribute name="MultiplexerService">jgroups.mux:name=Multiplexer</attribute> | <attribute name="MultiplexerStack">udp</attribute> | --> | | <!-- JGroups protocol stack properties. ClusterConfig isn't used if the | multiplexer is enabled and successfully initialized. --> | <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="false" /> | <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> --> | <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.AopEvictionPolicy</attribute> | <!-- Specific eviction policy configurations. This is LRU --> | <attribute name="EvictionPolicyConfig"> | <config> | <attribute name="wakeUpIntervalSeconds">1</attribute> | <region name="/_default_"> | <attribute name="maxNodes">0</attribute> | <attribute name="timeToLiveSeconds">300</attribute> | <!-- Maximum time an object is kept in cache regardless of idle time --> | <attribute name="maxAgeSeconds">300</attribute> | </region> | | <region name="/rgn/procedure/"> | <attribute name="maxNodes">0</attribute> <!-- No limit --> | <attribute name="timeToLiveSeconds">300</attribute> | <!-- Maximum time an object is kept in cache regardless of idle time --> | <attribute name="maxAgeSeconds">300</attribute> | </region> | </config> | | </attribute> | | </mbean> | </server>. | | On trying to put an object into cache we are getting the following nullpointer exception. Exception in thread "Thread-38" java.lang.NullPointerException at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863) at org.jboss.cache.TreeCache.put(TreeCache.java:3833) at org.jboss.cache.aop.PojoCache.lockPojo(PojoCache.java:635) at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:461) at com.rgn.cache.Cache.putObject(Cache.java:67) at com.rgn.dao.NewMediaDao.procedure(NewMediaDao.java:428) at com.rgn.dao.NewMediaDao.run(NewMediaDao.java:166) at java.lang.Thread.run(Thread.java:595) Can anyone shed some light on what we are doing wrong here. Thanks and Regards, Rahul View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122689#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...