[infinispan-dev] Management interface

Adrian Cole ferncam1 at gmail.com
Wed May 6 06:14:31 EDT 2009


This is interesting.  What is important, afterall?  In the case of a grid,
it is more like a quorum that allows operations to continue without data
loss.  I'm not sure if individual instances matter as complete sets of EC2s
could go up or down and there still be no effect on cluster as a whole.

Would it not be the cache instances, or jgroups configuration that are the
most important managed resource in this case?

-Adrian

On Wed, May 6, 2009 at 11:11 AM, Heiko W. Rupp <hwr at redhat.com> wrote:

> Manik Surtani schrieb:
>
>> Is there a way to use JGroups for discovery?  If the console was running
>>
>
> Yes of course.
>
>  in the same VM as any of the cache instances, it could delegate discovery
>> to the cache, which could expose a set of addresses.
>>
>
> The console (be it Jopr or Embedded Jopr) never connects to a managed
> resource itself, but the agent-plugin does this. So you could e.g. have
> an agent running within EC2 that has the Infinispan plugin, which talks to
> all the cache nodes and the server UI would run in the enterprise and would
> talk to that agent.
>
> The most difficult part would be to get the naming of the individual IS
> instances
> on the various hosts right (*) - especially when only one agent is managing
> multiple
> instances.
>
> (*) The name of a resource must not change on the next discovery run. That
> is
> why for example the process id is not allowed, as a process restart would
> find a
> different resource and the existing one would be marked as down.
>
>
>  Heiko
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090506/02677b6f/attachment-0001.html 


More information about the infinispan-dev mailing list