[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur
by bela@jboss.com
"manik.surtani(a)jboss.com" wrote : I inherently don't like using a static cluster size configuration. With larger clusters, nodes joining and leaving the cluster should be seen as "normal" and it should be able to scale up or down without reconfiguration.
|
This is not a static configuration, e.g. {A,B,C,D,E}. The only thing that's static is the primary partition size.
anonymous wrote :
| Correct me if I am wrong, but if you have {A, B, C} on switch S1 and {D, E} on switch S2, and if S2 fails, does JGroups deliver 2 view changes to {A, B, C} (one without D and one without both D and E) or just a single view change, without D and E? Assuming FD_SOCK is used for immediate switch failure detection?
|
Depends. usually you get 2 view changes, sometimes 1. Remember that if a switch goes down, the TCP connection in FD_SOCK will *not* be closed, so we'd have to rely on FD here.
anonymous wrote :
| If this is the case, can't a split brain threshold be used? I.e., if a view change is received in which more than N% of members are removed, assume a split brain as opposed to normal drop-offs?
No, because you can't rely on JGroups excluding all 'dead' members in *1* view. This depends on the failure detection and group membership protocol impl, and they might all be different.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084571#4084571
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084571
17 years, 1 month
[Design of POJO Server] - Re: Handling component references
by scott.stark@jboss.org
The first issue for a component registry is how to build the keys that describe a component. The most obvious starting point is that you have a structured name and indices based on the different types of references. For ejb-link style references, you have a name based on the deployment structure and ejb-name. For @EJB with a class, you have a name based on the deployment structure and business interface class.
A source based on an ejb-name:
{vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/ejb-name - points to the component metadata for the ejb-name component.
A source based on a business interface:
{vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/business-interface-class - points to the component metadata for the component providing the business-interface-class implementation.
Resolution of a reference then consists of trying various structured keys based on the referencing component structure and type of reference.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084568#4084568
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084568
17 years, 1 month
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur
by manik.surtani@jboss.com
I inherently don't like using a static cluster size configuration. With larger clusters, nodes joining and leaving the cluster should be seen as "normal" and it should be able to scale up or down without reconfiguration.
Correct me if I am wrong, but if you have {A, B, C} on switch S1 and {D, E} on switch S2, and if S2 fails, does JGroups deliver 2 view changes to {A, B, C} (one without D and one without both D and E) or just a single view change, without D and E? Assuming FD_SOCK is used for immediate switch failure detection?
If this is the case, can't a split brain threshold be used? I.e., if a view change is received in which more than N% of members are removed, assume a split brain as opposed to normal drop-offs?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084557#4084557
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084557
17 years, 1 month