Problem using JBossCache-1.2.2

[ashankerdas]

Hi,
I am working on jboss 3.2.3. I was trying out JBossCache in clustered mode. Started the server in "all" config. I am using JBossCache1.2.2. When i started the server, i got exception saying:
NoClassDefFound for org/jgroups/log/Trace.

On exploring, i found that the earlier version of jgroup.jar contained this file. However the new version has many changes compared to the previous one. I get the exception when the server tries deploying, cluster-service.xml.

Can anyone please tell me which jar files i need to include.

Thank you.

[ashankerdas]

To be more specific, there are files in jbossha.jar which refer to classes which were in the older version of jgroups.jar. Can i get a latest version of jbossha.jar which will work on JBoss-3.2.3, from some place?

Thank you.

[ben.wang]

1. Can you upgrade to 3.2.7? That should solve your problem.

2. If not, may be copy jbossha.jar from 3.2.7 back to 3.2.3 will work. Not sure though.

-Ben

[ashankerdas]

Hi,
Thanks for the reply. Since i can't change to other version of JBoss, I tried the second approach. I copied jbossha.jar from jboss-3.2.5 into the all/lib directory of jboss-3.2.3. It worked

However, i am facing the following problems(though not related to jbossha.jar).

I have a clustered environment setup. There are 2 nodes in the cluster.
Working on JBoss3.2.3. I have setup the JBossCache with the following values:
ISOLATION_LEVEL = SERIALIZED
CacheMode = REPL_SYNC
TransactionManagerLookupClass = org.jboss.cache.DummyTransactionManagerLookup

I have the following case:

- I put an object in cache. Say object "fqn/xyz"
On node1:
- I start a transaction T1 using the DummyTransactionManager

UserTransaction transaction = new DummyUserTransaction(DummyTransactionManager.getInstance());
 transaction.begin();

- I retrieve the object from cache on node1.
- I start modifying the object
- At the same time, when modification of "fqn/xyz" is going on, from node2, i start transaction T2 and retrieve the same object from cache.
- At node2 i start modifying the object


- Later at some point of time i put the modified object back into cache from both these transactions and issue commit on T1 and T2.
(Note: T1 and T2 are transactions on different nodes)
What i expected is, T1 would succesfully commit and T2 would rollback.

However, both T1 and T2 are rolled back. Is this behavior appropriate?

Assuming that it is correct behavior, what i expected was that when a rollback is done, whatever modified object that put in cache, should be rolled back and the initial state should be retained.
However what i found was that, even when the trasaction got rolled back, the modified contents STAYED in the cache.

I thought that since i was using DummyTransaction, i might be getting this wrong output so i tried with JBossTransactionManagerLookup. But even in this case the same behavior was observed. Am i going wrong somewhere?


Below is the code snippet (using DummyTransactionManager):

public void someOperation() {

UserTransaction transaction = new DummyUserTransaction(DummyTransactionManager.getInstance());

transaction.begin();

cache.get("fqn","xyz");

someTimeConsumingMethod();

cache.put("fqn","xyz");

transaction.commit();

}

My jboss-cache-cluster-service.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->

<server>

 <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>


 <!-- ==================================================================== -->
 <!-- Defines TreeCache configuration -->
 <!-- ==================================================================== -->

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

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

 <!--
 Configure the TransactionManager

 -->
 <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>



 <!--
 Isolation level : SERIALIZABLE
 REPEATABLE_READ (default)
 READ_COMMITTED
 READ_UNCOMMITTED
 NONE
 -->
 <attribute name="IsolationLevel">SERIALIZABLE</attribute>

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

 <!--
 Just used for async repl: use a replication queue
 -->
 <attribute name="UseReplQueue">false</attribute>

 <!--
 Replication interval for replication queue (in ms)
 -->
 <attribute name="ReplQueueInterval">0</attribute>

 <!--
 Max number of elements which trigger replication
 -->
 <attribute name="ReplQueueMaxElements">0</attribute>

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

 <!-- JGroups protocol stack properties. Can also be a URL,
 e.g. file:/home/bela/default.xml
 <attribute name="ClusterProperties"></attribute>
 ClustercConfig changed to ClusterProperties in the next line for testing
 -->

 <attribute name="ClusterConfig">
 <config>
 <TCP start_port="7800" bind_addr="10.44.60.136"/>
<TCPPING initial_hosts="10.44.60.131[7800]" port_range="1" timeout="3000"
num_initial_members="1" up_thread="true" down_thread="true"/>
<FD shun="true" up_thread="true" down_thread="true"
timeout="2500" max_tries="5" />
<VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
<pbcast.NAKACK gc_lag="100" retransmit_timeout="3000" up_thread="true" down_thread="true" />
<pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false" print_local_addr="false" down_thread="true" up_thread="true" />
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>

 </config>
 </attribute>


 <!--
 Whether or not to fetch state on joining a cluster
 -->
 <attribute name="FetchStateOnStartup">true</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 -->
 <!-- Jaikiran: Changed from 15000-->
 <attribute name="LockAcquisitionTimeout">45000</attribute>

 <!-- Name of the eviction policy class. Not supported now. -->
 <attribute name="EvictionPolicyClass"></attribute>

 <!--
 <attribute name="CacheLoaderClass">org.jboss.cache.loader.bdbje.BdbjeCacheLoader</attribute>
 <attribute name="CacheLoaderConfig">c:\tmp\bdbje</attribute>
 <attribute name="CacheLoaderShared">true</attribute>
 <attribute name="CacheLoaderPreload">/</attribute>
 -->

 <!--
 <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute>
 <attribute name="CacheLoaderConfig">c:\tmp</attribute>
 <attribute name="CacheLoaderShared">true</attribute>
 <attribute name="CacheLoaderPreload">/</attribute>
 -->




 </mbean>


 <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
 <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
 <!-- <depends>jboss.cache:service=TreeCache</depends>-->
 <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
 <!-- </mbean>-->


</server>

Thank you.