[infinispan-dev] Management interface

[Manik Surtani]

On 5 May 2009, at 20:48, Heiko W. Rupp wrote:

> 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

Not all VMs would be on the same physical host.

> - 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.

Again, that only helps with static configurations.  Think grids where  
nodes are started up/shut down dynamically and on-demand, based on  
computing need.  Think EC2 even, where the IPs of these nodes are  
allocated dynamically.

Is there a way to use JGroups for discovery?  If the console was  
running in the same VM as any of the cache instances, it could  
delegate discovery to the cache, which could expose a set of addresses.

>>> 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
>
> _______________________________________________
> 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