When you guys get to a state that you are happy with, could you please generate and post a diff between your branch and the trunk, so those of us that are time-impaired can be clear as to exactly what is being done? Thanks.
-Bill On Mon, 2007-02-12 at 11:42 -0500, Rajith Attapattu wrote: > A big +1 for this proposal. > > >2. Do not call the ContextListner in property get, set methods. > >- These events will not be captured by the listener. > In my opinion this is key for performance. Now this gives rise to the > problem waiting to long for replication, especially in the case of > long running invocations or asynch invocations (where the message > receiver returns before the "business logic" is fully executed. > > To counter that we disscussed on the other clustering thread the > following proposal. > We can introduce two modes. > 1) Container Managed replication > 2) Service Managed replication. > > Container managed replication will call update state when the > container things it's time to do so. > With user managed replication the service author has the discreetion > in calling updateState when ever he wants. The service author can call > it for every property change or at any given point as the author > things it's appropriate. > > If we can get the ContextListerner going on the trunk we can quiclky > add that to the cluster branch. Deepal ????? > > Rajith > > On 2/12/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: > Hi Rajith, All, > > ReplicationHandler can be placed at various places of the > Handler chain and it does replication both at its 'invoke' and > 'flowComplete' methods. FlowComplete methods get called after > the invocation of the MessageReceiver, so the state of the > contexsts get replicated without a problem even in the InOnly > case. > > Introducing this handler made things more flexible and reduced > coupling. I have another suggestion that could reduce coupling > further. > > The idea is to introduce a ContextListner. This will get > called in specific places like, > 1. When a context get created > 2. When a context get removed > 3. When a context get flushed. > > If we can have this feature we will be able to move clustering > code into a module. At initiation this module will register a > ContextListener which will allow it to listen to context > updates. > > For having a minimum affect on the performance there are > several things we can do. > > 1. Do not initialize the ContextListner Map until the first > Listener is added. > - This reduces the load to a 'null' check when no listeners > are available. > > 2. Do not call the ContextListner in property get, set > methods. > - These events will not be captured by the listener. > > 3. Not all the contexts should call the listeners. > - For e.g. we may decide not to call the ContextListeners for > events of the MessageContexts. > > This will not have any performance drawback from the approach > we are following now. But it will allow us to fully decouple > clustering code from the kernel. > > What do u think ? > > > Chamikara > > > > > > On 2/12/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > 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] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
