[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4180 - HA <-> JMX coupling
by bstansberry＠jboss.com
Very quick response:
Note the issue here is whether classes extend ServiceMBeanSupport, not whether they expose a JMX interface.
Also, have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118608 . Came up a couple weeks back. Showed me a benefit of subclassing ServiceMBeanSupport -- get to take advantage of the already coded methods that prevent duplicate lifecycle invocations when a MC bean is annotated with @JMX.
"galder.zamarreno(a)jboss.com" wrote :
| + Barrier, BarrierController, HASingletonController, HASingletonSupport and HAServiceMBeanSupport
|
| HASingletonController extends HASingletonSupport which sends notifications related to node becoming coordinator, or node stopping being coordinator. BarrierControler is the listener of these notifications, who's job is to start/stop of dependant services. Barrier is wrapper around the dependant service, which is started/stopped upon BarrierController's command via lifecycle methods.
|
| 1. BarrierController listens for JMX notifications, so should probably remain the same. Does not seem to make much sense to have JMX pulled out because it's its core business.
Makes sense
anonymous wrote :
| 2. Whether Barrier should be JMX aware is debatable. Extends ServiceMBeanSupport directly and does little more. It's a mere delegator.
No opinion. Not a priority either way.
anonymous wrote :
| 3. HASingletonController does nothing JMX related, except publicise (via getters) the configuration options for target start/stop methods. Needs JMX factoring out IMO.
|
The barrier counts on the notifications, and other users may be counting on the notifications as well, so if there is a refactoring to provide a non-JMX version, the std HASingletonController class needs to provide the notifications.
anonymous wrote :
| 4. HASingletonSupport knows when a node is coordinator or not, and via its parent, sends JMX notifications (only local notifications). HAServiceMBeanSupport can send JMX notifications locally or broadcast them accross the cluster. Both rely heavily on JMX functionality, so could stay the same.
| 5.- 5.- JBAS-3982 should take in account the decision on HAServiceMBeanSupport, which provides infrastructure for cluster wide notifications"
|
Sounds right.
anonymous wrote :
| + HASingletonElectionPolicyBase and HASingletonElectionPolicySimple
|
| This is new functionality to decide where to run HA singleton services instead of the coordinator. It makes sense to factor JMX out of these classes to separate functionality from any JMX managed methods. An election policy should be independent, like the load balance policies.
|
+1.
anonymous wrote :
| + FarmMemberService
|
Ignore this.
anonymous wrote :
| + ClusterPartition
|
| Does not make sense to have a non JMX version.
|
Sure it does. Again, the issue here is whether classes extend ServiceMBeanSupport, not whether they expose a JMX interface.
That said, changing this isn't a priority.
anonymous wrote :
| + UnifiedInvoker and UnifiedInvokerHA
|
| I'm not going to discuss legacy invokers here because they should remain as they are for backwards compatibility. To discuss JMX factoring out, let's focus on the unified invokers.
|
+1.
anonymous wrote :
| To factor out JMX from invokers makes sense to help unit testing and potentially make path for them to be migrated to Remoting (there's a JIRA on this) and be used standalone. It would also make my life a lot easier unit testing JBAS-4455 :)
|
Sadly, unlikely to happen before beta3 and thus not in 5.0.0. In any case, this should be driven by what's done with the non-HA version.
anonymous wrote :
| + DetachedHANamingService and HANamingService
|
| DetachedHANamingService uses JMX (via Query) to find an HAPartition with a given name via findHAPartitionWithName method. Couldn't find any references to this method and it's not a managed method either.
That method should be removed; the partition should be dependency injected. I'm quite sure it already is injected; that method is probably just leftover cruft.
anonymous wrote :
| + HASessionStateService
|
| This looks like legacy code, so no need to touch it?
|
| + PingJndi
|
| Once again, legacy code?
|
+1 to ignoring both. Don't even know what PingJndi is.
anonymous wrote :
| Thoughts? Comments? Bored? :)
Bored ;-)
Thanks much for this. Even if we don't change much for 5.0.0 this is most helpful.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090828#4090828
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090828
16 years, 8 months
[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-4180 - HA <-> JMX coupling
by galder.zamarreno＠jboss.com
Re: http://jira.jboss.com/jira/browse/JBAS-4180
------
The first thing I've done is evaluate our current usage of JMX, more specifically subclasses of ServiceMBeanSupport, in clustering related code. Here's the list:
- BarrierController
- Barrier (inner class of above)
- HAServiceMBeanSupport
- HASingletonSupport (extends above)
- HASingletonController (extends above)
- HASingletonElectionPolicyBase
- HASingletonElectionPolicySimple (extends above)
- FarmMemberService
- ClusterPartition
- UnifiedInvoker
- UnifiedInvokerHA (extends above)
- DetachedHANamingService
- HANamingService (extends above)
- HASessionStateService
- ListenerServiceMBeanSupport
- BarrierController (extends above)
- PingJndi
------
And below is my analisys of these classes:
+ Barrier, BarrierController, HASingletonController, HASingletonSupport and HAServiceMBeanSupport
HASingletonController extends HASingletonSupport which sends notifications related to node becoming coordinator, or node stopping being coordinator. BarrierControler is the listener of these notifications, who's job is to start/stop of dependant services. Barrier is wrapper around the dependant service, which is started/stopped upon BarrierController's command via lifecycle methods.
1. BarrierController listens for JMX notifications, so should probably remain the same. Does not seem to make much sense to have JMX pulled out because it's its core business.
2. Whether Barrier should be JMX aware is debatable. Extends ServiceMBeanSupport directly and does little more. It's a mere delegator.
3. HASingletonController does nothing JMX related, except publicise (via getters) the configuration options for target start/stop methods. Needs JMX factoring out IMO.
4. HASingletonSupport knows when a node is coordinator or not, and via its parent, sends JMX notifications (only local notifications). HAServiceMBeanSupport can send JMX notifications locally or broadcast them accross the cluster. Both rely heavily on JMX functionality, so could stay the same.
5.- JBAS-3982 could be resolved with the JMX factored version of HAServiceMBeanSupport.
+ HASingletonElectionPolicyBase and HASingletonElectionPolicySimple
This is new functionality to decide where to run HA singleton services instead of the coordinator. It makes sense to factor JMX out of these classes to separate functionality from any JMX managed methods. An election policy should be independent, like the load balance policies.
+ FarmMemberService
This class extends URLDeploymentScanner, but has no meaningful JMX methods, FarmMemberServiceMBean. Does not seem to require a JMX aspect to it. I guess in the future it could send notifications when a deployment was successfully deployed in all nodes, once farm deployments are atomic, but this has not been implemented yet.
+ ClusterPartition
Does not make sense to have a non JMX version.
+ UnifiedInvoker and UnifiedInvokerHA
I'm not going to discuss legacy invokers here because they should remain as they are for backwards compatibility. To discuss JMX factoring out, let's focus on the unified invokers.
To factor out JMX from invokers makes sense to help unit testing and potentially make path for them to be migrated to Remoting (there's a JIRA on this) and be used standalone. It would also make my life a lot easier unit testing JBAS-4455 :)
+ DetachedHANamingService and HANamingService
DetachedHANamingService uses JMX (via Query) to find an HAPartition with a given name via findHAPartitionWithName method. Couldn't find any references to this method and it's not a managed method either. Javadoc for DetachedHANamingService states: "Management Bean for the protocol independent HA-JNDI service. This allows the naming service transport layer to be provided by a detached invoker service like JRMPInvokerHA + ProxyFactoryHA.".
HANamingService's javadoc says: "Management Bean for HA-JNDI service for the legacy version that is coupled to the RMI/JRMP protocol. The DetachedHANamingService should be used with the appropriate detached invoker service."
I'm not sure about the meaning of the javadocs for these two services. The invokers they refer to are legacy, so maybe legacy these are legacy classes and we shouldn't touch them? Does HA JNDI without JMX makes sense? If you're using JNDI to start with, chances are you're in a managed environment.
In fact, any legacy/deprecated classes should be marked as such for newcomers to be aware of :)
+ HASessionStateService
This looks like legacy code, so no need to touch it?
+ PingJndi
Once again, legacy code?
-----
Thoughts? Comments? Bored? :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090812#4090812
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090812
16 years, 8 months
[Design of JBossCache] - Re: Removing classloader issues for PojoCache
by bstansberry＠jboss.com
Chat history related to above:
anonymous wrote :
| [14:43:27] Jason T. Greene: did you ever review my reply to the marshalvalue thread?
| [14:48:01] Brian Stansberry: i was a little unclear on #2; i.e. when the deserialization occurs and what gets passed to the callback
| [14:50:15] ? i.e. how it would be different from the current region-based marshalling
| [14:51:07] Jason T. Greene: it would just keep you from having to configure the region up front
| [14:51:27] ? and allow for you to make decisions at the node level
| [14:52:03] Brian Stansberry: ok, ic.
| [14:52:17] ? here's a sucky thing about region-based....
| [14:52:45] ? for a tx prepare, we need to figure out the region
| [14:53:10] ? we do that by checking the first method call in the set of method calls that make up the prepare
| [14:53:25] ? if a tx spans classloader regions, that breaks
| [14:54:24] ? i suppose a serialization manager could be more intelligent
| [14:54:44] Jason T. Greene: hmm shouldnt prepare deseralize each call separately according to the fqn
| [14:54:45] ? ?
| [14:55:41] Brian Stansberry: yeah, that would be better. DOH!
| [14:56:22] ? just serialize the elements individually and then wrap them up in the prepare method call
| [14:57:11] Jason T. Greene: yeah you could even do this intelligently with markers that prevent double buffering
| [14:59:40] Jason T. Greene: so the serialization manager suggestion was really because i was interpreting the problem being allocating the structure to fit the region model
| [15:01:01] Brian Stansberry: well, its more than that
| [15:01:18] ? assume the goal is to fit all session repl in a shared cache
| [15:02:03] ? for most usages, the session is represented by a single key/value pair in one node.
| [15:02:53] ? and most txs involve changing a single session
| [15:03:13] ? for that case, a wrapper obj is more efficient than passing a region-fqn as external metadata for every call
| [15:04:36] Jason T. Greene: ok so the issue is multiple classloaders in the same session right?
| [15:05:03] Brian Stansberry: no, multiple classloaders in the same cache; only one per session
| [15:05:27] ? I can either use something like region-based marshalling or wrap the cached objects
| [15:05:38] Jason T. Greene: oh i see
| [15:05:50] ? now i get what you are talking about
| [15:06:27] ? technically the region-fqn is duplicate information
| [15:06:38] ? you already know the region from the fqn
| [15:06:38] Brian Stansberry: yes
| [15:07:27] ? yes, although the Fqn is encapsulated as an arg in the MethodCall, and which arg depends on the method
| [15:08:12] ? also, an element of the fqn can itself be a custom type, as long as its below the region root
| [15:08:40] ? BTW that's an issue with Hibernate caching (which is a quite different use case)
| [15:10:43] Jason T. Greene: the first problem is an issue with the serialization format
| [15:10:54] ? the second is bigger problem
| [15:11:21] Brian Stansberry: +1
| [15:16:17] Jason T. Greene: I want to get rid of that usage in pojo cache
| [15:16:41] Brian Stansberry: which?
| [15:16:49] Jason T. Greene: custom types in an fqn
| [15:16:59] ? its used for maps right now
| [15:17:39] Brian Stansberry: the key for a map entry is the last Fqn element?
| [15:18:09] Jason T. Greene: yeah, it was done that way to make locking more efficient
| [15:18:29] ? and index retrieval is effecient as well
| [15:19:34] ? what i probably want to do is keep it like that for simple types
| [15:19:55] ? but when a custom type is used generate a hash based UUID
| [15:21:39] ? anyway its a problem i have to think about
| [15:21:48] ? because their are other issues with custom fqns
| [15:21:53] ? like cache loaders
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090809#4090809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090809
16 years, 8 months