[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