Channel creation - mux vs. old style

[brian.stansberry]

I think we are trying too hard not to fail in startService() if there is an issue with the mux configuration.

We do this:

1) If a JChannelFactory has been injected into the config, use it and propagate any exception.
2) If no JChannelFactory is injected, but there is a mux service ObjectName in the config, try to find a mux service in JMX and use it to create the channel.
3) If there is an error in #2, but there is an old-style channel config, use that to create the channel
4) If there is no old-style config, use the default properties to create the channel.

Three points:

1) #4 above is bogus. If they configured for mux and didn't specify an old-style config, failure to find the mux service should lead to an exception, not to a fallback on some default. The default properties should only be used if nothing else is configured. I'm going to change that.

2) Trying to find the channel in JMX is suspect, at least in JBoss AS where it can be dependency injected (even in 4.x). Manik put a comment in CacheImpl about that.

3) If we decide to keep the JMX lookup, if it fails, should we log a warn and fall back to the old style config, as in step 3 above, or rather throw an exception? (This is an irrelevant issue if we get rid of the JMX lookup).

(NOTE: please don't get rid of the JMX lookup yet, as I still need it in the AS integration. Want to get rid of the need for it, but haven't yet.)

[brian.stansberry]

Worse than I thought. Even if there is a exception in step 1 above, we catch the exception and try to create a channel from an old style config. If the JChannelFactory has been injected into the config, that's a clear sign it's meant to be used, so any failure should propagate.

[manik]

I agree with all of the above. This should be a lot more intelligent in understanding user intention and act accordingly.

1) If JChannelFactory is injected, ONLY attempt to use this or FAIL.
2) If an ObjectName is specified, ONLY attempt to use this or FAIL.
3) If an old-style config is provided, use this or FAIL.
4) ONLY use the default if nothing else is PROVIDED, not if nothing else WORKS.

I presume you'd need this in 1.4.x for AS 4.2? :/

[brian.stansberry]

Not critical, although it would be good.

Take that back - it's a pretty big deal -- at least the bit about not using the default properties. I came across this yesterday when the RuntimeConfig.reset() issue prevented use of the multiplexer. So 4 different AS services all opened channels using the default properties. All of which then began spewing log messages complaining about getting messages with a different channel name. Not good at all.

[manik]

Yuck.

Next 1.4.1 SP, I suppose?

[brian.stansberry]

Yeah, that should be OK. Retagging 1.4.1.GA seems like overkill. The fundamental problem yesterday was the reset() thing; the fact that it then opened channels with a default config and had a really exciting breakdown was more of a distraction than anything.

[brian.stansberry]

Getting around to dealing with JBCACHE-934. Looking at it, I don't see any reason to support injection of an object name as a config attribute and then having JBC code do a JMX lookup of the channel factory. The channel factory should just be injected, either directly into the RuntimeConfig, or indirectly via a setter in CacheLegacyJmxWrapper.

[brian.stansberry]

A little more on why I don't want to support JMX lookup of the JChannelFactory -- besides the fact that in an IOC world, writing lookup code seems bogus.

Doing a JMX lookup presupposes that the MBeanServer is available before the call to Cache.create(). Otherwise, you can't do the lookup. In an AS 3.2.x or 4.x environment, that was a safe assumption, as that's the way the ServiceController worked. But if someone had created their cache programatically, it might have broken. That is, they could instantiate their cache, call startService() and then register it in JMX.

In 2.0, the coupling between the JMX wrapper and the Cache lifecycle is weaker. There's no strong reason to assume JMX registration will occur before create(). Adding logic to CacheJmxWrapper so it can deal with a situation where create is called first just adds complexity.

[manik]

Dos it make sense to support both approaches? Perhaps for non-AS usage where doing a lookup makes sense?

[brian.stansberry]

It's really just a matter of whether we want to support a bit of convenience code. My inclination is to think we shouldn't as it's just cruft. But I don't feel that strongly about it.

I don't know that much about what kind of facilities other environments offer.

a) Can they parse a deployment descriptor (a la -service.xml, but their format), use it instantiate a pojo (aka CacheLegacyJmxWrapper) and inject config elements into it and then register that pojo in JMX?

If no, then the user is going to have to deal with JMX themselves anyway (programatically). In that case, providing a convenience method doesn't buy much. User still has to provide us a ref to the MBeanServer and the ObjectName of the JChannelFactory. They just avoid the trivial lookup call.

If yes to a), then

b) Does the facility in a) have the ability to inject complex mbeans a la the AS's "depends optional-attribute-name" feature?

If yes, then it's the same case as JBoss AS -- they should just inject the JChannelFactory.

If no, then we have a use case for JMX lookup.


If we do decide to support this, the ObjectName should be removed from Configuration, and be added as an attribute of CacheLegacyJmxWrapper (or maybe CacheJmxWrapper). That object then does the lookup during it's create call, and injects the JChannelFactory into the Configuration.

This will only work if user registers the CacheJmxWrapper in JMX before calling create(). Otherwise, no MBeanServer will be available to CacheJmxWrapper to do the lookup. I definitely think we shouldn't support attempting to find a JMX server the way we do in 1.4. That just leads to trouble. If people want JMX, they register the wrapper; wrapper gets a preRegister callback during registration, and from that the wrapper has a ref to the MBeanServer to use to register cache internals like the interceptors.

[manik]

a) Can they parse a deployment descriptor (a la -service.xml, but their format), use it instantiate a pojo (aka CacheLegacyJmxWrapper) and inject config elements into it and then register that pojo in JMX?

If no, then the user is going to have to deal with JMX themselves anyway (programatically). In that case, providing a convenience method doesn't buy much. User still has to provide us a ref to the MBeanServer and the ObjectName of the JChannelFactory. They just avoid the trivial lookup call.

Good point. I suppose in most cases there will be some custom "deployer" code to read a JBoss Cache XML file, instantiate the cache and then attach it to JNDI or JMX for use by apps.

The JMX lookup for a JChannel could be done programatically and injected I suppose.
This will be related to what we do for JBCACHE-1023.

[manik]

Looking at JBCACHE-1023, and with reference to this, how would we deal with potentially injecting both a ChannelFactory as wel as a Channel?

If the Channel is null, fall back to the ChannelFactory and use the CF to create a channel? And if the CF is null, create a new JChannel with cluster props (or default cluster props?)

Would be nice if we could combine the injection of a Channel and a ChannelFactory in a single call. What about just injecting a CF? For JBCACHE-1023, people could write a CF impl to return their channel.

[manik]

A bit of a PITA that org.jgroups.jmx.JChannelFactoryMBean doesn't extend org.jgroups.ChannelFactory - as this would be the cleanest interface to use here.

[brian.stansberry]

Looking at JBCACHE-1023, and with reference to this, how would we deal with potentially injecting both a ChannelFactory as wel as a Channel?

If the Channel is null, fall back to the ChannelFactory and use the CF to create a channel? And if the CF is null, create a new JChannel with cluster props (or default cluster props?)

+1. That's the intuitively understandable way.

A bit of a PITA that org.jgroups.jmx.JChannelFactoryMBean doesn't extend org.jgroups.ChannelFactory - as this would be the cleanest interface to use here.

I think the type in RuntimeConfig should be org.jgroups.ChannelFactory. I see now that AS 5 will have no problem instantiating a ChannelFactory, injecting it into a RuntimeConfig and also injecting it into an instance of org.jgroups.jmx.JChannelFactory. It can then register the org.jgroups.jmx.JChannelFactory in JMX in order to expose the management interfaces.

Key thing in the above is JMX is just a mechanism for exposing management interfaces. It doesn't and shouldn't play the service integration role it did in AS 4-style architectures. Service integration should be done by injecting pojos -- i.e. the plain org.jgroups.ChannelFactory.

[brian.stansberry]

Just a bit of philosophical overview to make more explicit what I'm thinking about JMX and 2.0:

1) JMX becomes something used for exposing mgmt info to mgmt tools a la jmx-console, JON, jconsole, whatever. Internally JBC doesn't use it. No JMX lookups, etc.

2) We provide wrapper classes that implement mbean interfaces. User is responsible for getting those registered in JMX. In the AS they can use the tools the AS provides to help them do that (e.g. MC parsing of -service.xml or -beans.xml), but getting it done is up to them. The effect of this is JBC never has to worry about:

a) figuring out what the MBeanServer is.
b) figuring out what ObjectName to use.

3) For external objects like a JGroups ChannelFactory, JBC has no interest in JMX. If user wants their channel factory registered in JMX, they should do that themselves. JBC is interested in the raw channel factory.

4) The one JMX-related thing JBC should do is allow its JMX wrapper classes to register mbeans for the interceptors. JBC takes responsibility for this only because the interceptors are internal details of the cache; making users get hold of them and register them is too much to ask. CacheJmxWrapper is able to perform this service because when it is registered it gets a callback informing it of the mbean server and its own ObjectName. From that it's easy to create unique names for the interceptors based off its own name and to then register them using the provided mbean server.