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