axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [Axis2] An approach for clustering Axis2
Date Fri, 08 Sep 2006 15:16:00 GMT
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 <devlists@hanik.com> 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* < rajith77@gmail.com
> > <mailto:rajith77@gmail.com>> 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* < chamikaramj@gmail.com
> >     <mailto:chamikaramj@gmail.com>> wrote:
> >
> >         Hi Deepal,
> >
> >         Please see below.
> >
> >         On 8/24/06, *Deepal Jayasinghe* < deepal@opensource.lk
> >         <mailto:deepal@opensource.lk>> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message