JBoss Cache and JBoss MC

[manik]

Now that we're finally up and running with our new SVN repo and new set of maven scripts, I'm about to get started with the MC and just wanted to run a few things by everyone.

Keeping in mind that JBC is meant to be a standalone product, for use within the AS, or in other app servers, or even in a standalone case (e.g., in a standalone java program), I'm thinking of the best way to do this wrt. MC integration.

The usual way for people to use the cache is to create one using the cache factory:
1: CacheFactory cf = DefaultCacheFactory.getInstance();
2: Cache c = cf.createCache(Configuration cfg); // cfg is a pojo that contains getters and setters for the various cfgs
3: c.create();
4: c.start();

So what I think is:
1. MC kernel is "created" when the cache factory creates the cache (line 2), with default values in jboss-beans.xml overridden with some values from cfg.
2. MC starts when cache.create() is called, and this instantiates and injects necessary beans.
3. MC stops when c.destroy() is called

Does this make sense? Am I on the right path here? If so, what would I use - for the above steps? BasicBootstrap?

Hoping for an answer from the JBoss-MC guys. :-)

[alesj]

Hoping for an answer from the JBoss-MC guys. :-)

;-)

I would do it differently. :-)

First, I would have just one MC Kernel instance per CacheFactory.
If Kernel already exists - e.g. we are in JBossAS env - use that one.
This could also apply when we integrate MC into other app servers.
But if we are standalone or not yet app. server integrated, create new Kernel instance and plugin CacheFactory as a singleton bean.

And then for each -cache.cfg.xml (having your own ParserDeployer) I would create as many Configuration beans that would actually be BeanFactory and would, together with CacheFactory, instantiate Cache instance on createBean invocation - which would also mean that that would apply create, start methods invocations.

Or something like this:
You already have CachaFactory present.
Then for each -cache.cfg.xml install new Configuration bean and new Cache bean. But the Cache bean would have MANUAL mode, meaning you would move it though MC states by calling create, start on somesort of wrapper that would delegate these calls to MC's Controller.

Does this make sense?

For standalone you would use BasicBootstrap or StandaloneBootstrap, it depends which suites you best.
And stopping the MC would be done when you stop CacheFactory instance.

[alesj]

"alesj" wrote:

And then for each -cache.cfg.xml (having your own ParserDeployer)

For the old/backcompatibility xml files.
For the new one's, using MC schema, you wouldn't need any parser. ;-)

But if I remember correctly you used XMBeans for old stuff, right?
So no parser there as well, since MC knows XMBeans. ;-)

[adrian.brock]

For doing a bootstrap:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/bootstrap/src/main/org/jboss/bootstrap/microcontainer/ServerImpl.java?revision=64576&view=markup

But I don't really get what your requirements are?
Why would you create a kernel for every cache?

In JBossAS we would want to inject the Cache[Factory] configured
via a JBoss deployment, e.g. deploy/jbossas-cache-beans.xml
We wouldn't want a seperate kernel.

More likely we want a cache specific schema that makes it easier to configure.
e.g. something like

@JAXBAnnotationsHere
public Cache implements BeanMetaDataFactory
{
 @XmlAttribute/Element(...)
 public setSomeProperty(...)

 List<BeanMetaData> getBeans()
 {
 // NOTE: This can be multiple beans
 return createTheEquivalentMetaDataForOurProperties();
 }
}

Then we can do:

<deployment xmlns="urn:jboss-bean-deployer:2.0">

 <!-- This gets converted to the BeanMetaData by the BeanMetaDataFactory above -->
 <cache xmlns="urn:jboss-cache:x.y">
 <some-property>blah</some-property>
 </cache>
</deployment>

Instead of

<deployment xmlns="urn:jboss-bean-deployer:2.0">
 <bean name="Cache" class="org.jboss.cache.UserShouldntHavetoKnowThis">
 <property name="someProperty">blah</property>
 </cache>
</deployment>

[adrian.brock]

The usual way for people to use the cache is to create one using the cache factory:
1: CacheFactory cf = DefaultCacheFactory.getInstance();
2: Cache c = cf.createCache(Configuration cfg); // cfg is a pojo that contains getters and setters for the various cfgs
3: c.create();
4: c.start();

The whole point of POJOising (IOC) is to get rid of this self configuration.
Instead the user would use JBossMC, Spring or something else
to inject the cache into their code.

@Inject/@Resource
public void setCache(Cache cache) {}
or
public void setCacheFactory(CacheFactory factory) {}

[manik]

Sorry for the slow response, been moving house and have had limited connectivity.

Adrian, thanks for the suggestion re: a cache-specific schema, that would certainly work very well.

Regarding exposing lifecycle and self-configuration, I don't think we can mandate that client code use an IOC framework, and I think we must assume that they don't use one. That still should not prevent me from using IOC internally within JBoss Cache.

Regarding a separate kernel per cache instance, I may be wrong here, but isn't this necessary to prevent namespace collissions? It is a perfectly valid usecase to have 2 cache instances in the same VM, with different configurations. Wouldn't the MC register bean instances under set names, and wouldn't these overwrite if the 2 cache instances share the same kernel instance?

[brian.stansberry]

I think it would be helpful if you described in a little more detail how you want to use the MC in JBoss Cache. We can already use the MC to build a configuration and pass it to the existing CacheFactory methods to instantiate the cache. This is what AS trunk already does for the web session and EJB3 caches. So I don't think that kind of thing is what you're talking about.

When you've mentioned this before I always had a vague notion in my head of using the MC to wire together the cache internals, i.e. build interceptor chains, plug in state transfer managers, etc. But what's never been clear at all to me is how this would work in terms of what the end user would configure. I wouldn't think we'd want 99% of end users having anything to do with anything beyond the existing Configuration object. I guess a goal is to allow the remaining 1% to override some stuff, e.g. add an extra interceptor.


(Adrian, +1 on the thanks for the cache-specific schema suggestion; I've written a few -beans.xml files to create a cache now, and this would be a big improvement. :-)

[manik]

I'd like to use the MC to wire together cache internals. The cache is basically few core objects (CacheImpl, UnversionedNode) some services (CacheLoaderManager, RPCManager, Notifier, CacheMarshaller, BuddyReplicationManager) and a bunch of interceptors in front of the core objects (TxInterceptor, CacheLoaderInterceptor, etc etc). The relationship between these objects are all controlled by the cache.create() method when the cache starts, which uses a Configuration object to determine which services and interceptors are needed and how they are configured.

This is where I think the MC can help; where the services and interceptors can be configured in a beans.xml file, which would control the implementations of each service/interceptor used as well as their relationship, e.g., inject a notifier into the NotificationInterceptor, a CacheLoaderManager into a CacheLoaderInterceptor, etc etc.

Regarding end users configuring a -beans.xml file, I would like to expose this as a possibility for "advanced" users, but also provide a much simpler configuration file for more typical use cases (no customisation of interceptors, notifiers, rpc managers, etc., but simple stuff like eviction policies, cache loaders as well as timeouts, cache modes, etc).

Maybe a well-designed cache-specific schema would allow me to achieve both in a single file.