Sure, resources can be found at:
A brief introduction
http://people.apache.org/~fhanik/tribes/docs/introduction.html
<http://people.apache.org/%7Efhanik/tribes/docs/introduction.html>
Simple summary
http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/trib
<http://people.apache.org/%7Efhanik/tribes/javadoc/org/apache/catalina/trib>es/package-summary.html
Downloads
http://people.apache.org/~fhanik/tribes/archive/
<http://people.apache.org/%7Efhanik/tribes/archive/>
You can take a look at the org.apache.catalina.tribes.demos.MapDemo
java -cp tribes-0.9.5.2.jar;commons-logging-api.jar
org.apache.catalina.tribes.demos.MapDemo
this example uses a primary/secondary backup strategy, there is also a
similar all to all map as well.
The replicated map extends HashMap, so if you implement your session manager to
use a HashMap all you need to do is replace this hashmap with a replicated one.
Take a look at
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/ha/src/share/org/apache/catalina/ha/session/BackupManager.java?view=markup
at the method
* public* *void* start() *throws* LifecycleException {
*if* ( *this*.started ) *return*;
*try* {
CatalinaCluster catclust = (CatalinaCluster)cluster;
catclust.addManager(getName(), *this*);
LazyReplicatedMap map = *new* LazyReplicatedMap(*this*,
catclust.getChannel(),
DEFAULT_REPL_TIMEOUT,
getMapName(),
getClassLoaders());
map.setChannelSendOptions(mapSendOptions);
*this*.sessions = map; //swap out the old hashmap for the replicated
hashmap
*super*.start();
} *catch* ( Exception x ) {
log.error(*"Unable to start BackupManager"*,x);
*throw* *new* LifecycleException(*"Failed to start
BackupManager"*,x);
}
}
The objects your store in your HashMap can implement the
org.apache.catalina.tribes.tipis.ReplicatedMapEntry interface, and by
doing that allow for diffs/deltas to be replicated.
just a few examples, I can give more if you decide to use this
implementation. Another option you have is to use the Jakarta JCS (Java
Caching System), Aaron there has done tons of work, and believe added in
a small module for replication as well.
Filip
Rajith Attapattu wrote:
Filip,
Thank you for picking up the baton. Can u please provide a list of
resources that people should be looking at if they are to use Tribes?
like where to download, documentation ...etc?
Chamikar and Chathura (and everybody else interested)... shall we get
started on the impl?
We can each choose an area and then start working on the code.
comments?
Regards,
Rajith
On 9/8/06, *Filip Hanik - Dev Lists* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
it all looks kosher to me. the logic that you are talking about is
axis
invocation logic.
in tomcat for example, we intercept the request with a valve, and
after
the request is complete, we simple check to see if the session was
updated,
and then notify the replicated map to flush out the changes.
I'm not familiar enough with axis to know the details of the
invocation
chain, but I can imagine it being pretty similar.
I agree with that it should be easy and non intrusive, goes for all
software :)
Filip
Rajith Attapattu wrote:
> Hi All,
>
> As Chamikara pointed out we have left the proposal for about a week
> now for any comments/concerns.
> I guess people are happy so far with the proposal.
>
> Shall we move on to the implementation stage?
>
> Filip could you please have a look and let us know your ideas?
>
> Regards,
>
> Rajith
>
> On 8/25/06, *Rajith Attapattu* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> Chamikara,
>
> I guess the other point that we don't have a clear grasp is the
> "specific points" where axis2 will invoke the cluster interface.
>
> We should try to make this as easy and non-intrusive as
possible.
> If we add this in AbstractMessageReceiver and the
> AbstractTransportSender then we clearly need to indicate this in
> the documentation.
>
> If somebody wants to write there own message receiver or
transport
> sender then either they should extend the abstract class or
make
> sure to include the cluster code somewhere if they decide not to
> extend the abstract classes.
>
> Regards,
>
> Rajith
>
>
> On 8/25/06, *Chamikara Jayalath* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Hi Deepal,
>
> Please see below.
>
> On 8/24/06, *Deepal Jayasinghe* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Hi Chamikara;
>
> Chamikara Jayalath wrote:
>
> > Hi All,
> >
> > Here is a summary of the ideas we discussed in the
hackathon.
> >
---------------------------------------------------------------------------------------------
>
> > 1. It is fine to go with the abstraction approach.
Axis2
> will come
> > with the ClusterManager interface and there will be
> specific points in
> > code where this interface will be invoked.
>
> What are those specific points ? .....
>
>
>
> This is something we have to decide. From which points of
> Axis2 the ClusterManager methods will be invoked. For
example:
>
> * touchProperty() method may have to be called from the
> getProperty and setProperty methods of the AbstractContext.
>
> * updateState() may get called from the TransportSenders and
> MesageReceivers.
>
>
> >
> > 2. Replicating MessageContexts and OperationContexts
> would be too
> > costly. So we will only be replication
ConfigurationContexts,
> > ServiceGroupContexts and ServiceContexts.
>
> +1 , actually you dont need to replicate o.c and m.c ,
> because if
> something goes wrong while we are processing the message
> then we are not
> going to handle that case . So what we only require
is to
> store s.g.c ,
> and of course we need to replicate them only if
service is
> deployed in
> application or soapsession scope.
>
>
>
> Ok. Thanks for the info.
>
>
> >
> > 3. Weather all the cloned contexts will be
available in
> all the nodes
> > or not will be up to each ClusterManager
implementation. Some
> > implementations may choose to group nodes as a
resource
> optimization
> > mechanism.
> >
> > 4. The state of the above three contexts are basically
> defined by
> > their property bags. So we should replicate the
state of
> the property
> > bag correctly using the ClusterManager.
>
> yes
>
> >
> > 5. There will be specific points in the Axis2 message
> execution chain
> > where a specific node will be broadcasting its
state. One
> point may be
> > the MessageReceiver. Another may be the
TransportSender.
>
> If you try to broadcast the state at any of those , then
> if some one is
> writing new message receiver or transport sender
then they
> need to do
> those as well.
> What I think is , do those inside AxisEngine , broadcast
> - immediately after it invoke m.r (when it recieve a
> message)
> - immediately after it call t.s (inside send method)
>
>
>
> How about AbstractMessageReceiver and the
> AbstractTransportSender ? If we add ClusterManager
invocations
> there, they will be reflected in all TransportSenders and
> MessageReceivers right ?
>
> Thanks for the valuable ideas :-)
>
>
> Chamikara
>
>
>
>
>
>
------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.2/442 - Release Date:
9/8/2006
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.2/442 - Release Date: 9/8/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
