tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r400201 - in /tomcat/container/tc5.5.x/modules: groupcom/build/ groupcom/src/share/org/apache/catalina/tribes/ groupcom/src/share/org/apache/catalina/tribes/membership/ groupcom/test/java/org/apache/catalina/tribes/test/ groupcom/test/java/...
Date Sat, 06 May 2006 13:55:36 GMT
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:[])

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.
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

As you can see, tribes is extremely customizable, only you imagination 
is the limit.


Peter Rossbach wrote:
> Can you please explain how domain memberships at future works?
> Peter
> Am 06.05.2006 um 00:59 schrieb
>> Author: fhanik
>> Date: Fri May  5 15:59:35 2006
>> New Revision: 400201
>> URL:
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message