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]>> 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]>> wrote:
Hi Deepal,
Please see below.
On 8/24/06, *Deepal Jayasinghe* < [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]
For additional commands, e-mail: [EMAIL PROTECTED]
