12:55 p.m.
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the
discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536382#536382
--------------------------------------------------------------
Brian Stansberry wrote:
> Jason Greene wrote:
> When you think about it, a server-group, and a cluster are really the same thing,
the only difference is that the cluster has an additional set of services that a basic
group does not.
Yes, but isn't the set of capabilities that a server has defined by its profile? We
could say that defining a server as part of a cluster means that additional capabilities
are added beyond what's in the profile. But then we are dividing the definition of a
profile into two places. Also, exactly what capabilities should be added if a server is in
a cluster is unclear
I think there is a definite overlap between the definition of a profile and the definition
of a grouping. The only way I can see having both in domain.xml is to have the profile
function as a template like you mention earlier (or to pull all common config stuff out of
a group).
> Jason Greene wrote:
> When you think about it, a server-group, and a cluster are really the same thing,
the only difference is that the cluster has an additional set of services that a basic
group does not.
Yes, but isn't the set of capabilities that a server has defined by its profile? We
could say that defining a server as part of a cluster means that additional capabilities
are added beyond what's in the profile. But then we are dividing the definition of a
profile into two places. Also, exactly what capabilities should be added if a server is in
a cluster is unclear.
I think this depends on the definition of a profile. To me our previous definition of
profile focused much more on internal implementation details (how to build a server with
ejb3 (which jars etc)). When I look at the domain model I am looking at it from a
configuration standpoint. Specifying things like "jndi should be clustered on port
blah blah blah". There should be a thread pool with X threads, etc
A very simple concept of a cluster is that it is a server-group that
also exposes some predefined configuration properties that need to be kept consistent
throughout the group. (A server-group would not have such properties by default, although
users could add custom ones.) Things such as:
* Group name (current -g)
* Type of intra-group communication to use by default (udp, tcp)
* Default interface to use for intra-group communication
* Default multicast address to use
* other defaults less commonly changed
Right this is exactly what I was getting at. It also would represent what
resources are available (datasources etc).
A cluster might also have some management capabilities besides what is available to a
server-group, although I'm not sure what. It should be possible for example to perform
a (rolling) redeployment to a server-group.
A separate discussion is how communication will occur between servers who are not members
of a cluster. There needs to be a group communication mechanism that spans the entire
domain.
I think the best way to address this is that everything in a domain will have two
communication services that are distinct from everything used in clustering:
1. Configuration syncing
2. Deployment
These services could be implemented in a number of ways, but will likely need to be a
simple/specialized protocol. It might even necessitate a node agent of some sort. However
I think thats a conversation for later, the important thing is the notion that synching
must be possible to non-clustered nodes.
> This was what I meant by the cluster-service tag, a way to
specify how a group would cluster a particular service (maybe not all services should be
clustered). Although it was just something I through out there as an example. A better way
likely exists
Currently how we cluster a particular service is defined in that service's
configuration, it's not something applied externally. And the details of what needs to
be configured are often disparate between different services, so I'm not sure those
configs can profitably be externalized into some common configuration element.
Ah, or are you talking about "clustered-service" as a wrapper to describe how
to manage the service, e.g. how to (re)deploy across cluster?
Don't read too much into it, it was just a generalization. Substitute
clustered-service with "jgroups-group" or "ha-jndi".
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536382#536382]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5840
days inactive
5840
days old
jboss-dev-forums@lists.jboss.org
0 comments
1 participants
participants (1)
-
Jason Greene