3:53 p.m.
This is related to
https://jira.jboss.org/jira/browse/ISPN-71
and I'm starting this thread to discuss how we should approach this,
given that Heiko Rupp from the JOPR team's just joined the mail
list. :-)
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?
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.
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?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
4:56 p.m.
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
5:12 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
9:48 p.m.
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
10:56 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
11:11 a.m.
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
12:14 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:49 p.m.
On 6 May 2009, at 11:14, Adrian Cole wrote:
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?
I tend to agree with Adrian, although if an individual node were to be
'bounced' for whatever reason, naming as far as management is
concerned could be something statically configured. E.g., we could
introduce a configuration element for node name, such that the
management console would see information scoped on a few things:
+ app-1-cluster
+ data-cache
+ node1
+ node2
+ node3
+ some-other-cache
+ node1
+ node2
+ node3
+ app-2-cluster
- etc -
Current configuration allows you to specify cache name and cluster
name. Node name could be added. E.g.:
<global>
<transport clusterName="app-1-cluster" nodeName="node1">
</transport>
</global>
<cache name="data-cache">
....
</cache>
If nodeName is not specified then network address is used. These
details could then be exposed via JMX for collection by the JOPR agent.
So assuming that solves the naming problem, I still think the main
problem is discovery.
So it makes sense that the console talks to agents, and agents talk to
the process being run locally, which is fine. But how does the
console find agents? :-) Or is the console's location statically
configured on each agent so the agent reports its location on
startup? This makes sense to me...
-Adrian
On Wed, May 6, 2009 at 11:11 AM, Heiko W. Rupp <hwr(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
3:06 p.m.
Manik Surtani schrieb:
would see information scoped on a few things:
+ app-1-cluster
+ data-cache
+ node1
+ node2
+ node3
+ some-other-cache
+ node1
+ node2
+ node3
+ app-2-cluster
Yeah, that tree with cluster->cache makes sense.
If the list of nodes is relatively static, it makes sense too to expose
them as child resources.
If they are relatively dynamic, it will be better to have them just
exposed as count metric and
then have operations on cache level to obtain the list of nodes and
perhaps some code to
manipulate them.
So it makes sense that the console talks to agents, and agents talk
to
the process being run locally, which is fine. But how does the console
find agents? :-) Or is the console's location statically configured on
That is something Jopr takes care of. Bascially when you install the agent,
you pass some properties for the server(s) location. There is multicast
support for this too.
each agent so the agent reports its location on startup? This makes
sense to me...
This does not directly cater for agents on changing IP addresses, but
this is
a Jopr internal issue and does not change at all the way plugins are
written.
One thing we may need to take care of (but then, it may be no issue at
all) is to not
discover a cache or cluster from different agents. But then if it an
issue we need to
take care of that in Jopr (imho).
Heiko
2:44 p.m.
Adrian Cole schrieb:
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.
This is a good question, that I was thinking about too
Would it not be the cache instances, or jgroups configuration that
are
the most important managed resource in this case?
Help me with the naming conventions here.
1 Infinispan istance can have n caches, that each has 1 jgroups channel?
In the cloud you have x IS instances with n caches.
So in this case, we could have the cache as top level element
below the "IS subystem". And the number of IS instances as
just a numeric metric.
In a later version of Jopr, we will have the possibility of "related
resources".
In this case we don't need the strict parent-child relation that we have
now.
Heiko
5:56 p.m.
On 6 May 2009, at 13:44, Heiko W. Rupp wrote:
Adrian Cole schrieb:
> 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.
This is a good question, that I was thinking about too
> Would it not be the cache instances, or jgroups configuration that
> are the most important managed resource in this case?
Help me with the naming conventions here.
1 Infinispan istance can have n caches, that each has 1 jgroups
channel?
No, they share the same channel.
In the cloud you have x IS instances with n caches.
Yes. Typically 1 infinispan instance per JVM, but not strictly so.
You would have 1 infinispan instance per Channel though.
So in this case, we could have the cache as top level element
below the "IS subystem". And the number of IS instances as
just a numeric metric.
In a later version of Jopr, we will have the possibility of
"related
resources".
In this case we don't need the strict parent-child relation that we
have now.
I think the parent-child relationship works, IMO. Let's not speak of
Infinispan instances since this is a concept that doesn't strictly
exist. A better way to look at it is this:
* You create a CacheManager. This starts a channel. So there is a 1
to 1 relationship here.
* You could start > 1 CacheManager per VM, but I don't see this being
common.
* You use the CM to start > 1 caches. These caches share the same
Channel started by the CacheManager.
* When a channel is created, it has a ClusterName.
So you could organize things by cluster name, and within that, each
cluster has multiple cache managers (named either by IP Address or by
some form of 'node-naming' we can work out), and within that, a set of
named caches.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
5:59 p.m.
Also, Heiko, you may want to have a look at this thread:
http://lists.jboss.org/pipermail/infinispan-dev/2009-April/000041.html
where we discussed instance naming.
On 6 May 2009, at 16:56, Manik Surtani wrote:
On 6 May 2009, at 13:44, Heiko W. Rupp wrote:
> Adrian Cole schrieb:
>> 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.
>
> This is a good question, that I was thinking about too
>
>> Would it not be the cache instances, or jgroups configuration that
>> are the most important managed resource in this case?
>
> Help me with the naming conventions here.
>
> 1 Infinispan istance can have n caches, that each has 1 jgroups
> channel?
No, they share the same channel.
> In the cloud you have x IS instances with n caches.
Yes. Typically 1 infinispan instance per JVM, but not strictly so.
You would have 1 infinispan instance per Channel though.
> So in this case, we could have the cache as top level element
> below the "IS subystem". And the number of IS instances as
> just a numeric metric.
> In a later version of Jopr, we will have the possibility of
> "related resources".
> In this case we don't need the strict parent-child relation that we
> have now.
I think the parent-child relationship works, IMO. Let's not speak
of Infinispan instances since this is a concept that doesn't
strictly exist. A better way to look at it is this:
* You create a CacheManager. This starts a channel. So there is a
1 to 1 relationship here.
* You could start > 1 CacheManager per VM, but I don't see this
being common.
* You use the CM to start > 1 caches. These caches share the same
Channel started by the CacheManager.
* When a channel is created, it has a ClusterName.
So you could organize things by cluster name, and within that, each
cluster has multiple cache managers (named either by IP Address or
by some form of 'node-naming' we can work out), and within that, a
set of named caches.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:56 p.m.
New subject: MBeans (was Management interface)
Hi,
I've set up a little standalone cache and am looking at the MBeans.
domain:cache-name=[global],jmx-resource=CacheManage // is '[global]'
always true?
has an attribute Defined Cache Names which for me is
'[myCustomCache(created)]'
But at domain: I get "node" 'myCustomCache(local)' with some MBeans
below it.
Is this created/local/[global] intentionally? Does this change when
e.g. a 2nd cache
enters the room or when I set some configuration?
Thanks
Heiko
1:14 a.m.
New subject: MBeans (was Management interface)
Some components are global (i.e., they are shared by all caches
created by the same cache manager). Others are scoped to the specific
cache, in which case you would see the cache name instead of [global].
Mircea can speak more about this. Mircea?
On 15 May 2009, at 19:56, Heiko W.Rupp wrote:
Hi,
I've set up a little standalone cache and am looking at the MBeans.
domain:cache-name=[global],jmx-resource=CacheManage // is
'[global]' always true?
has an attribute Defined Cache Names which for me is
'[myCustomCache(created)]'
But at domain: I get "node" 'myCustomCache(local)' with some MBeans
below it.
Is this created/local/[global] intentionally? Does this change when
e.g. a 2nd cache
enters the room or when I set some configuration?
Thanks
Heiko
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
9:22 a.m.
New subject: MBeans (was Management interface)
Am 16.05.2009 um 01:14 schrieb Manik Surtani:
Some components are global (i.e., they are shared by all caches
created by the same cache manager). Others are scoped to the
specific cache, in which case you would see the cache name instead
of [global].
Ok. I don't mind seeing an Mbean name with 'global' and brackets in it.
Where we need pay attention is that the name should not change over time
or at least have enough unique components.
If a cache could have a run state that is expressed by the xx in
'myCustomCache(xx)',
I'd rather expose that as an MBean attribute than as a part of the name
Thanks
Heiko
11:13 a.m.
New subject: MBeans (was Management interface)
On 16 May 2009, at 08:22, Heiko W.Rupp wrote:
Am 16.05.2009 um 01:14 schrieb Manik Surtani:
> Some components are global (i.e., they are shared by all caches
> created by the same cache manager). Others are scoped to the
> specific cache, in which case you would see the cache name instead
> of [global].
Ok. I don't mind seeing an Mbean name with 'global' and brackets in
it.
Where we need pay attention is that the name should not change over
time
or at least have enough unique components.
If a cache could have a run state that is expressed by the xx in
'myCustomCache(xx)',
I'd rather expose that as an MBean attribute than as a part of the
name
Run state? You referring to cache mode? Yes, this can be expressed
as a separate MBean. Perhaps the Configuration should be an MBean so
that you get this plus any other config information via JMX.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
2:08 p.m.
New subject: MBeans (was Management interface)
Am 16.05.2009 um 11:13 schrieb Manik Surtani:
> If a cache could have a run state that is expressed by the xx in
> 'myCustomCache(xx)',
Run state? You referring to cache mode? Yes, this can be expressed
as a separate MBean. Perhaps the Configuration should be an MBean
so that you get this
Probably cache mode :) But then it is sort of a state, when it can
change dynamically. Putting dynamic information in the
MBean name is a PITA (we have seen that with the MDB -
https://jira.jboss.org/jira/browse/JBAS-1568
) if this prevents the unique
identification of this entry (over time).
I was thinking, that the (local) could change as a result of an api
call to (global) - in this case I think it would be better to put
(local) and (global) in an Mbean attribute.
Also on the CacheManager this cache is identified as
'myCustomCache(created)' while in the MBean names it is
'myCustomCache(local)',
which is IMO not consistent.
plus any other config information via JMX.
It will be definitively a plus if configuration would be available via
JMX as this allows to display this in Jopr and also allow to
change it from there.
Heiko
5647
days inactive
5658
days old
infinispan-dev@lists.jboss.org
16 comments
4 participants
participants (4)
-
Adrian Cole -
Heiko W. Rupp -
Heiko W.Rupp
-
Manik Surtani