Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <45018691.4080300@hanik.com>
Date: Fri, 08 Sep 2006 10:04:49 -0500
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] An approach for clustering Axis2
References: <9d4ec10b0608100936h1378de29i4f9e094cb54b49f5@mail.gmail.com>
	 <9d4ec10b0608100951i1eff0fcdl412c6c506a363294@mail.gmail.com>
	 <44DB803A.8060202@opensource.lk>
	 <9d4ec10b0608101722k7dd62ff5jbb27eda7bbf6d8b2@mail.gmail.com>
	 <003801c6bd13$2679c2a0$9a019f95@ads.iu.edu>
	 <f5f5e0730608231849p1af28dcdkb15bf60c443e3064@mail.gmail.com>
	 <9d4ec10b0608240436j17099dccwc7575b702c578ae6@mail.gmail.com>
	 <44EDD2DF.4050705@opensource.lk>
	 <9d4ec10b0608250344r4d19bd8ch7162e2f72a70d230@mail.gmail.com>
	 <f5f5e0730608250717o733adc35ybbd79322a0b5f903@mail.gmail.com>
 <f5f5e0730609080722o34797102of155dacf784e816b@mail.gmail.com>
In-Reply-To: <f5f5e0730609080722o34797102of155dacf784e816b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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