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]> 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,
RajithOn 8/25/06, Chamikara Jayalath < [EMAIL PROTECTED]> wrote:Hi Deepal,
Please see below.On 8/24/06, Deepal Jayasinghe < [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)Thanks for the valuable ideas :-)
How about AbstractMessageReceiver and the AbstractTransportSender ? If we add ClusterManager invocations there, they will be reflected in all TransportSenders and MessageReceivers right ?
Chamikara
