JBC and RPC

[ben.wang]

This has been discussed before regarding to the RPC functionality in JBossCache. In 1.4 and before, we have a "deprecated" RPCTreeCache to address the problem with a RPC layer to share the same channel with TreeCache itself such that a user can make a cache call along with her own RPC calls.

I can agree that JBossCache should detach itself from RPC functionality. However if I need to do JBC call along with RPC call, what can I do? I need two things:

1. A wrapper class similar RpcTreeCache for user to register the handler and also the callRemoteMethods. This should be fairly easy already by copying the RpcTreeCache that Brian did. So let's call this class RpcProvider. However, where does this class belong? We know HA-JNDI needs it in clustering. PojoCache will need it. And also some other users like this post: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93270

So a logical conclusion is that it should sit in JBC library maybe a package name like: org.jboss.cache.rpc.RpcProvider.

2. A way to create and obtain Jgroups multiplexer channel. This is pretty much provided inside JBossAS. However, for standalone mode, what's the best approach? Someone needs to create the jgroups channel and bind it into JMX. Then both JBC (already doing it) and RPCProvider will need to see if it needs to obtain a multiplexer channel. If RpcProvider is detached from JBC, then it will needs it own configuration xml to provide multiplexer service name. An extra file to deal with. So still not ideal. To me, if JBC can directly expose its channel to RpcProvider, then case solved.

What do people think?

[manik]

I still don't think JBC is the place for a generic RPC library. Thats what JGroups RpcDispatcher is there for.

[ben.wang]

Calling RPCDispatcher is no problem. Key is how to share the same JGroups channel.

How about we expose the JBC channel in the CacheSPI, say, getJChannel()? This way, a regular Cache user won't have access to that API but a customized provider can.

[brian.stansberry]

The multiplexer shouldn't really be tied to JMX; you should be able to inject the same JChannelFactory pojo into both a JBC instance and some other RPCDispatcher-based class. But, all we can do now is call a setter in the Configuration, passing a String with the multiplexer service object name. That works fine in the AS (until Scott Stark reads this post and tells me it's not acceptable), but Ben's right, it's too painful in a non-JBoss AS environment.

One question is where to do the injection:

1) In the Configuration. But then Configuration is no longer a simple, lightweight, Serializable object.
2) In the CacheSPI. But then a major piece of configuration information is no longer in the Configuration.

The same question applies with the TransactionManager. The whole TransactionManagerLookupClass business seems silly when it should be possible to inject the TransactionManager.

My vote is these things should be injected into the Configuration. The Configuration encapsulates all the external inputs needed to build the cache.

How about we expose the JBC channel in the CacheSPI, say, getJChannel()? This way, a regular Cache user won't have access to that API but a customized provider can.

Giving access to the JChannel doesn't help much, since JBC puts an RpcDispatcher on top of it, plugs in a very custom Marshaller, etc. If a user had access to the JChannel without access to all that stuff, all they could do would be send messages that would cause exceptions on the other end when our marshaller didn't know how to handle them.

[ben.wang]

Agreed. If we can't make the multiplexer sharing easy to do, then calling JGroups RPSDispatcher is no big deal.

+1 to inject it into Configuration object.

[manik]

My concern with the Configuration approach is that I'd see it as a static object - something that contains static configs and that can be reused.

But I do see your point re: the TM and Channel. Perhaps the Configuration could have a Runtime attached to it which contains these, and this Runtime is transient/destroyed when the cache is stopped?

[brian.stansberry]

Sorry - slow response on this one -- too many threads this week :-)

Segregating these kinds of things into a separate transient Runtime subobject sounds fine. Without objection I'm going to proceed down that line now, as it solves some issues with wiring things together in the AS.

I'd like to explore more what you're thinking about here though in terms of reuse.

I was thinking I'd like to have a service that's somewhat like the JChannelFactory, but instead for cache configs. Service creates (or is injected with) a bunch of named configs on startup. Users then say "give me the "HttpSession" config. Service hands it out.

I was thinking in terms of cloning the config though, instead of using a shared ref. All of the testImmutability("xyz") stuff in Configuration kind of rules out a shared ref.

Usage I was thinking about:

jboss-web.xml has properties "cacheConfigName" and "cacheMode". The "cacheConfigName" is almost never set; defaults to "HttpSession".

When webapp is deployed, it accesses the cache config service, gets a Configuration, changes it's cacheMode to match jboss-web.xml, gives it a unique clusterName, and creates the cache. Voila, cache per webapp. REPL_SYNC/REPL_ASYNC easily configurable per webapp. No activate/inactivateRegion, partial state transfer, problems with choosing a buddy who doesn't have the webapp deployed, etc.

In this scenario, the webapp would *like* to have the TransactionManager and Multiplexer service already in the config. The MC injects them into the configs it uses to create the cache config service. When a config is cloned by the service, the refs to TM and Mux remain. Not absolutely needed, but nice.

[manik]

Segregating these kinds of things into a separate transient Runtime subobject sounds fine. Without objection I'm going to proceed down that line now, as it solves some issues with wiring things together in the AS.

Ok.

I'd like to explore more what you're thinking about here though in terms of reuse.

I haven't thought too far down this line yet, I just think it may be useful in future, like some of what you mentioned above. I wouldn't attempt to do this for 2.0.0 though; perhaps 2.1.0? I presume this would have quite an impact on your using such features in AS clustering though... ?

[brian.stansberry]

Yes, it would impact things, although hopefully not in a problematic way. I haven't thought it through, but I'd think what I described above could be added in a later 5.x release without any overly-bad compatibility issues. We'd just have to make sure that webapps configured the old way still work. That's really an issue in the AS code.

For 2.0.0 if we can think a bit about the Cloneable implementation of the configuration classes, that would be great. I added a JIRA -- http://jira.jboss.com/jira/browse/JBCACHE-845 -- if we get it done for 2.0.0, great; if not we can push it out.

[manik]

Cool, thanks.