JBossDeveloper

I'm referring to JmxConfigurator.registerChannel()

-1 on region based stats. Defer that until 2.x

After posting on the wrong thread, let me reiterate it properly here :-)

Why are trying to build a management infrastructure inside the cache?

The cache is made up of a number of "plugins"/advices that each have their
own statistics.

These need to be exposed for management, but how they are
exposed for management is something that should be solved by the user of the cache
not the cache itself.

If you start defining *fat* interfaces on the cache you are making invalid assumptions
about how the cache is implemented/constructed and losing your ability to change
it in future.
e.g. JBoss's EJB container has this problem where the pluggable components (pool/cache)
are exposed to the jsr77 layer via the EJBContainer.
It is less of a problem there since jsr77 does at least define some standard statistic
formats for EJBs.

In summary, expose the stats as pojos and let a/the management layer deal with
their exposure/consolidation on a usecase basis.
Ben got close to this with his initial comment, Manik's "where would it stop?"
is answered by "where the user wants it to stop", rather than "where you have decided it should stop". :-)

"JerryGauth" wrote:

Adrian - re:

...expose the stats as pojos and let a/the management layer deal with
their exposure/consolidation on a usecase basis.

I'm not clear on what you're proposing here. I think the current vision is that each interceptor would have an associated mbean to expose its statistics. Is this in line with your thinking or are you indicating that interceptors should provide some type of statistics object (unique to each interceptor) that clients could manipulate as desired?

So we simply maintain the state for statistics that cannot be generated, like number of bytes sent, hit/miss ratios etc, in each interceptor.
Then another subsystem exposes them, e.g. similar to what I do in JGroups. That subsystem could for example generate an MBean, which exposes *all* attrs/operations in one bean.
So by default we'd provide such a management subsystem, which for example exposes the cache and all interceptors in the same hierarchical manner JGroups does it. However, this can be replaced, for example by JBossNetwork.
This doesn't necessarily need to be a callback, it can simpy be a method that is called or not by the management subsystem.

Now I finally know where the reference of "fat interface" come from? :-)

I think what we should strive for is defining first and foremost a good (or proper) management "framework" for JBoss Cache.

Like I mentioned, I like the idea of interceptor based MBean since we are moving toward interceptor pattern anyway. So we should borrow Bela's idea from JGroups. And then, among each interceptor, it is probably their own responsibility to provide different stats based on different provider (and this can be hierarchical). Again, example like eviction or cache loader all have different providers.

Like Adrian mentioned, it is the management caller's responsbility to aggregate all these information. But the very least, we will have hierarchy of mbeans.

Finally, the concept of region in 2.0 is just like multiple sub-cache instances. So instead of multiple cache instances that we use now inside JBoss AS, we will have just one that have multiple regions, so to speak.

Impact on management? To me it is just one more hierarchical layer in the future.

I think in this case we can have the interceptors implement MBeans, because we're already using JMX.
However, as Adrian previously pointed out, the code that creates the management info and exposes it, should be separate from the code that provides management info.
So, like in JGroups, maybe a static method that creates the MBean for the TreeCache(Aop) and 1 for each interceptor.

Jerry,

To answer some of your questions. How about we do this?

Define an TreeCacheInterceptorBaseMBean interface that looks like:

Interface TreeCacheInterceptorBaseMBean
{
void statsCollection(boolean true);
}

And we define in TreeCache, an andditional API called:

registerMBean(TreeCacheInterceptorBaseMBean mbean)

Then if an interceptor wishes to add itself to the management hierarchy, he calls this api (after he implements the BaseMBean). Of course, the flag of stats collection should still applies.

This way we get a cleaner hierarhcy that TreeCache has control over.

+1

+1 as well