Refactor TreeCache dependencies

[starksm64]

Right now the 1.2 TreeCache implementation is coupled to the jboss remoting implementation and jmx via the jboss ServiceMBeanSupport helper class. Its also coupled to JNDI for binding of the instance/proxy. These dependencies are not needed in all deployment contexts and should be factored out as aspects on top of the base TreeCache.

[belaban]

I am still thinking that the idea of running JMS server on each node is sane.

As far as replication is concerned, here is what we can do:

1) If a sender or recepient happens to be in the middle of a connection to a node which fails, then the HAClientIL proxy can detect that and setRollBack on the transaction.

2) Instead of keeping a distributed state of all Topics and Queues that were created statically or at run time, the HAClientIL can help at create time.
When a JMS client attempts to create a new Topic or Queue the HAClientIL can intercept the call, iterate over all participating nodes and create the topic/queue on each one.

3) When a new node joins the cluster partition, an initialization service can
a) connect to any of the other peers that has already been initialized and up to date
b) enumerate all topics and queues and create them locally
c) while initializing, receive requests for create/remove topics/queues from remote clients, but only enqueue them, until the replication is finished.
d) Once replication is finished, execute all create/delete requests and then
e) become an up to date member

[anil.saldhana]

TreeCache.java is 3000 plus lines of code. May be suitable to refactor some of the code into helper class. Also is it possible to extract an interface for easier viewing of the API, TreeCache provides?

[jimcross]

Is there anything happening with this issue?

The last post was over a year ago and the cache still seems to have a lot of dependencies.

Right now running even a standalone out of container instance requires over 8 separate jars, including such "odd" ones as jgroups.jar and concurrent.jar, as well as jboss-jmx even though we don't need jmx capabilities.

One jar would be best but 2 or 3 would be reasonable. Or, perhaps the features could be loaded more dynamically and only if required.

[manik]

Dependencies have improved since the last post here, but still exist to a fair degree, including deps to jgroups.jar (transport layer for replication), concurrent.jar (concurrent processing utils - needed for as long as we support pre-5.0 JDKs), and other jboss libs such as jboss-jmx. We do plan to look at this, but is not as high a prio as many other tasks on the roadmap.

Feel free to add comments/vote on the issue - http://jira.jboss.com/jira/browse/JBCACHE-137

Cheers,
Manik