Cannot Handle _put

[lasmith]

We use JBoss 4.0.4GA with hibernate and have upgraded the JBoss cache to 1.4.0GA. We currently only use it for a local cache (ie not replicated). We run on JDK 1.5.0_07-b03.

Intermittently we get similar messages to the one below:

10:41:48,437 INFO [OptimisticNodeInterceptor] Cannot Handle Method _put(GlobalT
ransaction::365, /com/msxi/warrantySystem/ejb/entities/AuditAction/com.msx
i.warrantySystem.ejb.entities.AuditAction#8, item, CacheEntry(com.msxi.warrantyS

This can be different classes and doesn't appear to happen consistently (though I admit I haven't done extensive testing). I just wondered what this message is caused by, if it has any unwanted sideaffects and how I can stop it happening. Currently this causes no apparent impact on running the application but we are only in a development environment. When we go out into production I am not sure if this will have an impact or if it can safely be ignored??

Laurence

[manik]

This only happens under load? Very odd.

Could you pls paste a bit more of the log - about 5 lines before and after?

What version of Hibernate are you using and which CacheProvider? (From the log pattern I'm guessing you're using Hibernate!)

[lasmith]

This DOESN'T happen under load - I am the only person using the system (its in development on my local PC running XP). Here is a bit more of the log:

2006-08-22 16:03:09,421 DEBUG [com.msxi.warrantySystem.ejb.dao.GenericHibernateDAO] getting com.msxi.warrantySystem.ejb.entities.AuditType instance with id: 1
2006-08-22 16:03:09,421 DEBUG [org.jboss.cache.interceptors.OptimisticNodeInterceptor] unable to find node /com/msxi/warrantySystem/ejb/entities/AuditType/com.msxi.warrantySystem.ejb.entities.AuditType#1 in workspace.
2006-08-22 16:03:09,421 DEBUG [org.jboss.cache.interceptors.OptimisticNodeInterceptor] unable to find node /com/msxi/warrantySystem/ejb/entities/AuditType/com.msxi.warrantySystem.ejb.entities.AuditType#1 in workspace.
2006-08-22 16:03:09,421 INFO [org.jboss.cache.interceptors.OptimisticNodeInterceptor] Cannot Handle Method _put(GlobalTransaction::166, /com/msxi/warrantySystem/ejb/entities/AuditType/com.msxi.warrantySystem.ejb.entities.AuditType#1, item, CacheEntry(com.msxi.warrantySystem.ejb.entities.AuditType)[THIRD PARTY,An audit conducted by a third party], true, 0)
2006-08-22 16:03:09,421 DEBUG [org.jboss.cache.interceptors.OptimisticNodeInterceptor] Adding Method _put(GlobalTransaction::166, /com/msxi/warrantySystem/ejb/entities/AuditType/com.msxi.warrantySystem.ejb.entities.AuditType#1, item, CacheEntry(com.msxi.warrantySystem.ejb.entities.AuditType)[THIRD PARTY,An audit conducted by a third party], true, 0) to modification list
2006-08-22 16:03:09,437 DEBUG [com.msxi.warrantySystem.ejb.dao.GenericHibernateDAO] get successful, instance found

All the other log output is my own output. We use the bundled hibernate: 3.2.0.cr2. This deployed as a HAR and is configured to use the tree cache availble in JNDI like so:

 <attribute name="CacheProviderClass">org.jboss.hibernate.cache.DeployedTreeCacheProvider</attribute>
 <attribute name="DeployedTreeCacheObjectName">jboss.cache:service=HibernateTreeCache</attribute>

The tree cache mbean is configured like so:

<server>
 <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
 <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=HibernateTreeCache">
 <depends>jboss:service=Naming</depends>
 <depends>jboss:service=TransactionManager</depends>
 <attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute>
 <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
 <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
 <attribute name="CacheMode">LOCAL</attribute>
 <attribute name="UseReplQueue">false</attribute>
 <attribute name="ReplQueueInterval">0</attribute>
 <attribute name="ReplQueueMaxElements">0</attribute>
 <attribute name="ClusterName">TreeCache-Cluster</attribute>
 <attribute name="ClusterConfig">
 <config>
 <UDP mcast_addr="228.1.2.3" mcast_port="48866" 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" />-->
 <FD_SOCK/>
 <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false"/>
 <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" 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="true" down_thread="true"/>
 </config>
 </attribute>
 <attribute name="FetchInMemoryState">false</attribute>
 <attribute name="SyncReplTimeout">20000</attribute>
 <attribute name="LockAcquisitionTimeout">15000</attribute>
 <attribute name="InitialStateRetrievalTimeout">20000</attribute>
 <attribute name="EvictionPolicyClass"/>
 <attribute name="UseRegionBasedMarshalling">false</attribute>
 </mbean>
</server>

[manik]

You need to use Hibernate's OptimisticTreeCacheProvider (new in Hib 3.2.0) if you wish to use Optimistic Locking in JBC.

I'd also recommend upgrading to Hibernate 3.2.0.cr3 - see http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796

[lasmith]

I did as you said and it seems to have stopped the output. One thing I had to do was change the tree cache mbean (in the service file) to be in a treecache.xml file on the classpath. I couldn't see a way to get it to lookup via JNDI??

I guess that is another post though...

Anyways, thanks for your help.

Laurence

[manik]

Hmm, one for the hibernate forums, to try and grab a running cache from JNDI. Otherwise, I know a lot of people have written their own provider classes, extending the appropriate packaged TreeCache provider, to look up a running cache from JMX/JNDI/whatever.