Hi Deepal, This is not simply about the message coming in and going out of the system. For example one very important use case of clustering Axis2 is to allow users to replicate their state information in a set of Axis2 Nodes (of course he must be storing those in the context hierarchy). Such cases can only be caught by listening through context classes and a handler won't help here. Also there are some other events like Mep completion which we cannot capture using a handler.
As for the performance, when clustering is not present we can reduce this to a couple of null checks. (Don't think this will have a considerable affect) Chamikara On 2/7/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi Chamikara ; Do we really need to the listen to the event changes ?
As I know whenever a message coming into the system there will be many
getProperty and setPoropert method calls. That simply impl you that there are a number of context changes for a req. So you need to update the replicas irrespective of the message, therefore you do not need to listen to specific event . What you can do is , you can add a handler (or handlers) to update the replicas when message coming to the system and when a message going out from the system. Thanks Deepal > Hi Deepal, > > The problem we had in clustering is having the listen to specific > events in the Axis2 execution. For example context creation, context > removal, mep completion. So it is not possible to do it with a module > based approach :-(. > > But performance is certainly in our mind. > > Chamikara > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
