Excellent! That will definitely help. Two followup questions:

1. Are there any issues with using the HEAD version of JBOSSCache in JBOSS 3.2.6? We are currently using 3.2.6 in production and I've tried putting JBOSSCache 1.2 in 3.2.6. Unfortunately, after working through the new JNDI settings I ran into some ClassCastExceptions.

2. How would one lock the cache for state transfer to ensure that the cache is entirely duplicated when a new node is added to the cluster? That way there is no timeout that can short-circuit the state transfer process. Or have I missed something and with the fix you just mentioned the cache already does this?

Thank you again and I appreciate your help.

Hi Bela,

Thank you very much for the advice. Already tried putting the jboss-remoting.jar in the \lib directory and to follow that path of thinking I got the following exception:

2005-01-25 12:36:11,617 ERROR [org.jboss.cache.TreeCache:bindToJndi] failed binding to JNDI as {locatorURI=rmi://localhost:10444, name=MDVTreeCache}, exception=org/apache/commons/httpclient/HttpMethod

After figuring out that the above class does not exist in 3.2.6 I copied the commons-httpclient.jar from jboss-4.0.1 and the error went away. Now JBOSSCache registers the MBean in JNDI but when I look it up I get a ClassCastException. The line of code where I look up the JNDI reference looks like:

cache = (TreeCache) context.lookup("XXXX");

I'm continuing to research the problem. Any ideas/insight would be most appreciated.