Yes. We can do that. But it will be much helpful if you can give your feedback while the idea being discussed (so that we will not have to keep doing changes repeatedly)
Thanks, Chamikara On 2/12/07, Bill Nagy <[EMAIL PROTECTED]> wrote:
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]
