Please see below.
On 8/24/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
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.
Ok. Thanks for the info.
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
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 ?
Chamikara