[infinispan-dev] Management interface

Heiko W. Rupp hwr at redhat.com
Tue May 5 15:48:36 EDT 2009


Manik Surtani schrieb:
> So infinispan stores - simplistically - key/value pairs.  Where these 
> entries actually exist - if using distribution - is something which 
> users have little control over (unless enforced using a specific 
> hashing algorithm and controlling key hashcodes).  In general though, 
> in a cluster of say 10 nodes, a key/value pair - or entry - could be 
> mapped to any n nodes (where n defaults to 2).
>
> I think the ability to locate an entry if given a key may be useful 
> for a console.  This functionality can be exposed as a JMX operation 
> on the cache.
>
If it is exposed as JMX operation, it can easily be incorporated in a 
plugin.
> Yes, we do require JDK 5+.  And a lot of information already is 
> exposed via JMX.  Ok, so that takes care of the remoting problem - but 
> how about discovery?  Please don't say static configuration!  :-)
No, not really. There are several options, that need to be perhaps 
checked in turn.
- if running in an AS, Infinispan would be a child of the AS, so after 
AS discovery, Jopr would search for a specific mbean naming pattern for 
the Infinispan subsystem (more on that later). If found, the next round 
would look for children of that, which could be individual channels.
- if running as standalone java process, we would need to run a process 
query to search for either some specific string (e.g. Tomcat has this 
'Bootstrap' class)
or just look at all java processes found if they expose some Mbeans
- if the process query does not work, the user can still manually take 
the infinispan server into inventory by explicitly giving some 
jmxremoting url. Most of the time this would also require setting user 
name /password.
>
>>
>> One key point and rule is that a resource (e.g. a cache instance) 
>> needs to have a unique name that may not change over time.
>
> It would - a combination of cache name and address.  Although the 
> address may change since it is a combination of IP and port number, 
> and if a port range is not specified, this could change over 
> disconnection and reconnection.
Well, that needs to be prevented - I guess I need to better understand 
the Infinispan architecture and use cases to propose something.

About the logical architecture:

Usually a plugin is 'self-contained' meaning that its functionality 
comes from itself and does not require code changes on other plugins. 
Meaning that if you e.g. want to create new channels from the UI, the 
plugin needs to have all code for that. It is not possible to have the 
"add channel" command on the AS resource, as this would mean changing 
the AS plugin and also conditionally checking if Infinispan is present.
So what one usually does here is to have a "Subsystem" as the top node 
of a plugin and then the individual resources (=channels) as children. 
That way the "create channel" would live on the subsystem.

About configuration:

Jopr has the ability to do group configuration (changes). Often this is 
done by the plugin writing a changed version of an XML file. If you want 
to go strictly remote (one agent taking care of several Infinispan 
instances on several hosts), the change mechanism needs to be remoted 
over Jmx.

About groups:

Jopr is able to group resources together for various purposes. Groups 
can be built on compatible resources (= of the same type) and mixed 
resource types. The latter is of interest for authorization purposes.
We have a thing called DynaGroups that allows to specify an expression 
on how a group is to be built. This expression can be evaluated e.g. 
every minute to take new nodes into account.
Compatible groups allow to take metrics for the whole group, configure 
the group, and also run operations on the whole group.
The plugin does not need to take care of any of this.

 Heiko




More information about the infinispan-dev mailing list