-
1. Re: Management Attributes by Release
belaban Jan 6, 2006 1:10 PM (in response to jerrygauth)all of them into 1.3, none into 1.4 ? :-)
-
2. Re: Management Attributes by Release
jerrygauth Jan 6, 2006 2:28 PM (in response to jerrygauth)OK. We just need to associate them with the appropriate interceptors and add the corresponding mbeans if they haven't been added yet. Seems like identifying the interceptors that require mbeans and then creating them would be a good place to start.
-
3. Re: Management Attributes by Release
jerrygauth Jan 6, 2006 2:38 PM (in response to jerrygauth)One attribute request was for cache "elapsed time running." This is trivial to provide but the output can be presented in several ways.
1) Just show elapsed time in seconds (or milliseconds) since the cache was placed in service. The Sun JVM mbean takes this approach as it shows how long the JVM has been in use in milliseconds. Milliseconds does seem like overkill here so maybe seconds would be better.
2) Just show when the cache was started (e.g., show the corresponding Date object). This is the approach taken by the JBoss Server mbean.
3) Show the elapsed time in a user friendly String (e.g., 2 days, 3 hours, 5 minutes and 10 seconds would be 2:03:05:10)
Any recommendations? -
4. Re: Management Attributes by Release
ben.wang Jan 6, 2006 10:46 PM (in response to jerrygauth)Jerry,
If it is not too time consuming, I'd really like to see the following in your list into 1.3. :-)
Attrs:
* bytes send and recd
* replication units send and recd
* initial state transfer sent and rcvd (from last time since the node can leave and re-join later)
Stats:
* avg read/write time
So for eviction, we will wait for EvictionInterceptor in 1.4 to implement the attrs and stats. I will create this shortly.
For Cache loader and passivation, we already have the interceptor. Can you work with the corresponding interceptor owner (like Manik and Hany for passivation) to come up with some attrs and stats?
Great work! -
5. Re: Management Attributes by Release
ben.wang Jan 6, 2006 10:47 PM (in response to jerrygauth)I'd say go for #1.
-
6. Re: Management Attributes by Release
ben.wang Jan 6, 2006 10:51 PM (in response to jerrygauth)The other thing about attrs and stats is that they are related wrt to cache stop and start service (or leave and join a group). For example, when a user do:
cache.stop() and then cache.start() again, should we re-set the stats?
Same question goes for leave and join a group.
What do others think?
-Ben -
7. Re: Management Attributes by Release
jerrygauth Jan 20, 2006 3:46 PM (in response to jerrygauth)Ben - what are "bytes sent and received?" What are we measuring here? Same question for "replication units sent and received."
Avg read/write time is now implemented.
Not sure whether we should reset stats when the cache is stopped and restarted. I suppose it could be handled easily by having the statistics interceptor register a listener with the cache to catch the stop and start events. Since stopping and starting the cache seems to leave the contents intact, I don't think we need to reset the statistics as they're still valid. ElaspedTimeRunning would be somewhat incorrect since the cache was running continuously; this statistic isn't normally reset during a resetStatistics operation. My inclination would be to leave the statistics as is for now.
It was useful for me to look at stop and start as I noted the dynamic mbean registration process fails with a stack trace on a restart since the mbeans have already been registered. Will fix asap. -
8. Re: Management Attributes by Release
ben.wang Jan 22, 2006 11:37 AM (in response to jerrygauth)1. bytes sent and received. This is more of an attribute from JGroups, actually, to measure the total bytes sent and recevied, either during this call stack (or over a period of time).
2. replication units sent and recvd. This measures how many sent/recvd thru JGroups method call in this call stack, e.g., we can have mutiple remove/put calls.
3. OK. Somehow we need to have an option to say that stop/restart should flush out the cache contents (and stats). But this is not high priority.
THanks,
-Ben -
9. Re: Management Attributes by Release
jerrygauth Jan 23, 2006 12:11 PM (in response to jerrygauth)Some followup questions -
1. TreeCache doesn't currently expose its JChannel reference. Consequently in order to obtain bytes sent and received, it seems like I would need to do one of the following.
a) Modify TreeCache to expose the JChannel reference so that the statistics interceptor can work with it.
b) Modify TreeCache to expose the underlying statistics via its mbean. Then the statistics interceptor can make the information available by querying TreeCache (as it does now to display number of nodes and attributes)
2. Regardless of which option we choose for the previous issue, it seems likely that when JGroups channels become sharable, the bytes sent and received by a channel will no longer be associated with a single cluster such as a replicated TreeCache instance. Is this correct? -
10. Re: Management Attributes by Release
brian.stansberry Jan 23, 2006 1:25 PM (in response to jerrygauth)Can TreeCacheMarshaller help here? Right now we only use this class if they want to register special classloaders, but it would be trivial to modify things so we always use it and the cache's "useMarshalling" switch gets passed to it to control how serialization/deserialization is done.
This way all objectTo/FromByteBuffer calls could update statistics in this class (number of calls and number of bytes). Don't know if this would match what you're looking for. -
11. Re: Management Attributes by Release
belaban Jan 23, 2006 11:33 PM (in response to jerrygauth)Isn't there a getChannel() method on TreeCache ?
I suggest though to expose the channel via the Channel MBean that is aleardy exposed, so let's avoid duplication. -
12. Re: Management Attributes by Release
ben.wang Jan 24, 2006 12:26 AM (in response to jerrygauth)Jerry, you question of future channel multiplexing will pollute the bytes sent/recd is right. We need to have a separate counter from each sender. So in a sense we will need to have a way to intercept this.
-
13. Re: Management Attributes by Release
jerrygauth Jan 24, 2006 7:54 AM (in response to jerrygauth)No - there is no getChannel() method on TreeCache.
I'm not clear on how to get the channel mbean associated with the TreeCache instance. I know how to get a channel mbean for a standalone JGroups configuration that's defined in an mbean such as is doen with DemoChannel. But how does this relate to a JGroups configuration embedded in a TreeCache mbean?
Is is possible to define the standalone JGroups configuration and then refer to this configuration within the TreeCache configuration so that the TreeCache configuration doesn't prescribe its own channel? Is this where we're going with channel multiplexing? -
14. Re: Management Attributes by Release
belaban Jan 24, 2006 10:18 AM (in response to jerrygauth)Yes, I think it might be a better idea to simply not include bytes sent/received, and delegate it to JGroups