[infinispan-dev] Management interface

[Manik Surtani]

On 5 May 2009, at 15:56, Heiko W. Rupp wrote:

> Manik Surtani schrieb:
>> So here is what I see as a need: a GUI console (probably based on  
>> JOPR) that would:
>>
>> * provide info on the state of the cluster
>> * be able to locate entries via some interface
>> * visualise key statistics of each cluster node - memory  
>> consumption, cache hit/miss ratio, transaction success rate,  
>> network-level metrics such as throughput, etc
>> * perform management of the cluster - shut down, start nodes
>> * manage configuration?
>>
> Can you elaborate a little more on the 2nd item (locate entries)?

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.

>
>> The last one is probably optional.  The thing to keep in mind is  
>> that cache instances may not run in the same environment as an app  
>> server so even if the console requires an app server, the  
>> individual cache nodes should not.  Of course, if the cache is used  
>> within an app server, any advantages that come from that could be  
>> made use of, such as communication of common management information  
>> in an app server cluster for the embedded console.
> When I assume that Infinispan requires JDK5+, all the information  
> can be exposed through MBeans - when Infinispan lives in an AS,  
> tooling can use
> existing connections to the AS instance, otherwise standard jmx  
> remoting can be used.

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!  :-)

>> For starters, Heiko, how does JOPR manage remote instances?  Does  
>> it require its own agent to be loaded in each remote VM with its  
>> own communication channel?
> Well.... :)
> By default we say that on each machine (platform in Jopr terms) an  
> agent should be installed, as this also allows to gather machine  
> stats etc, which may be very helpful in determining issues (e.g.  
> because system cpu is at 100% or a network adapter broke down).
> But it is very well possible to have one agent reach out over remote  
> connections to multiple cache instances.
>
> 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.

> I have started a jboss cache plugin at Jopr -- this can be run  
> within AS 5.1cr1 and embedded Jopr, (or at least should be able to),  
> so you could have a look at how this can look.
> Heiko
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org