sure thing,
The current implementation was:
- add a domain field
- broadcast the domain field
- change replication code to accomodate for the field
- change server.xml to set the domain
- replication only occurs within the domain
The exact same functionality could have been achieved:
- change mcastAddr in server.xml
- replication only occurs within the domain
So as you can see, so much code was written that could have been done
with one tiny configuration change. And, the comm layer had no benefit
of it either,
so it was an applicatin specific need, and the code trickled down all
the way to the comm layer,
and that is the problem with the old app. many features needed in the
app layer, were coded in the comm layer and the other way around.
If the data was only valuable to the application that sits on top, then
it should be managed by the application on top.
The functionality still exists:
http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/tribes/MembershipService.html#setPayload(byte[])
When a channel is created today, the application can set a custom
payload (domain,admin JMX port,load averages,anything you can think of)
can be broadcasted. So the feature is still there, its just application
specific. The comm layer knows nothing about domains.
With the custom payload you have lost 0 features over the old
implementation, but you have gained a lot more flexibility, as you not
are limited to just broadcasting a domain, you can broadcast all kinds
of useful data.
Remember, that you can also build a custom interceptor that modifies
both membership and message data as it passes through the channel, only
your imagination becomes the limitation here.
For example, TcpFailureDetector, a simple implementation that overrides
the multicast membership for failure detection.
http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.html
this interceptor keeps its own membership and if a member times out, it
will verify the timeout with a connection attempt.
This is just a simple example of how an interceptor can override
implemented membership logic, you can create an interceptor that
implements all kinds of logic to manipulate membership.
What we've done with "ha" and "groupcom" modules is to split logic to
keep it where it belongs.
I have compiled a little introduction to Tribes which gives you a basic
understanding of the feature set
http://people.apache.org/~fhanik/tribes/docs/introduction.html
As you can see, tribes is extremely customizable, only you imagination
is the limit.
Filip
Peter Rossbach wrote:
Can you please explain how domain memberships at future works?
Peter
Am 06.05.2006 um 00:59 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Fri May 5 15:59:35 2006
New Revision: 400201
URL: http://svn.apache.org/viewcvs?rev=400201&view=rev
Log:
Removed domains, since we are doing so many changes, there is no
reason we can't implement that correctly
M
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
