Hey Chamikara, Thanks for making the changes, I was busy with Qpid work so couldn't even do the Null change we discussed.
However I have a concern about moving updateState from the Engine and placing this in a handler. The handler approach will only work if the MEP is IN_OUT. If this is a IN_ONLY operation then there is no outflow, so update state wan't be called. That is why I put it in the engine. (see the disscussion on the other clustering thread, about using flowComplete() as a replication point) Regards, Rajith On 2/12/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Deepal, On 2/12/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > > Hi Chamikara; > > > Hi Rajith, All, > > > > I did some changes to the clustering code. Please send your comments > ... > > > > 1. Changed signatures of the addContext, removeContext, updateState > > methods to take an AbstractContext. > > > > This makes the methods more general. IDs can be always obtained by > > going through the passed contexts correctly. > > > > 2. Added a flush() method to the AbstractContexst which calls the > > clusterManager.updateState() method when clustering is enabled. > Can we change the method name flush() , how about update(); I'm OK with changing the name. But not sure weather 'update' is the correct name. The idea of this method is to notify Axis2 to get sync with the updated state of the context (In our case replication). Chamikara > > > This allows Service authors to write their code in a transparent > > manner. I.e . if they hv done their state changes with flush() calls > > they will not have to do any changes to make their services > clusterable. > > > > 3. Moved the replication point of the execution chain into a Handler. > > > > There is no need to hard code this into the AxisEngine or > > MessageReceiver. By placing the ReplicationHandler anywhere in the > > handler chain we can change the replication point as needed. Most > > probably this will be placed at the end of the flows. > > (please see the clustering/conf/axis2.xml). > > > > 4. Added a isContextClusterable (AbstractContext) method to the CM. > > > > ClusterManagers can say what contexts they are interested in > > clustering, this will be useful to the Service authors. > > > > 5. Moved the addContext() method calls out of the constructors of the > > Context classes. > > > > It seems like it's better to have these outside. When we are in the > > constructor we do not have a fully initiated context object. For e.g. > > the serviceGroupContextId does not get setted at the time the SGC get > > created. > > Currently, this made me call clusterManager methods from several > > places of the core. But I was talking to Deepal about introducing some > > factories to create Context classes, which will make things much > cleaner. > > Yes , let's do that. And that will cleanup the code as well. > > > > > 6. Removed the NullClusterManager - as we discussed in the mailing > list. > > > > I also got your sample working with these changes. Will try to do some > > additions to it. > > Great. > > Thanks > Deepal > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
