Hi What I was done is simply make sure that synapse stared only if underlying environment has stared property.
If the listeners are belonged to axis2 (I believe it is an abstraction related with axis2 architecture - design decision), initialization of those should be done by axis2 as it is the only one responsible for enforcing semantic of its abstractions. Therefore, if the axis2 say that it has been started properly, we have to trust it. We always need to preserve semantic which say synapse will be only started if underlying environment has been stared. I agree on effects of system down time, but I cannot agree on staring listeners after synapse as a solution. If the listeners part of axis2 , axis2 should do that. If it is needed to preserve the delivery guarantee (delivering message to synapse), best solution may be the message queuing (persistence communication) at transport (axis2) level. It cannot validate how much this difficult or any issues. But this is the solution many system use. Other solution may be failure model for receive omission with notification failure. This is any way currently happening if any message is came before starting listeners (By sending transport level error messages). We can apply same concept by sending error indicating synapse is not ready (may be mapping error to http or any application level protocol or soap fault) so that client can retry. Thanks Indika On Tue, Mar 31, 2009 at 11:13 AM, Hubert, Eric <[email protected]> wrote: > Hi all, > > unfortunately at the moment I'm still not able to help much with this > discussion as I did not spend enough time to understand the coupling of Axis2 > and Synapse in detail. > > Generally what Indika writes about the decoupling of transports and mediation > engine makes definitely sense from my high level view. > > The only point where I disagree is the startup of listeners. It seems > impossible to me "to compensate" broken requests. > In any system listeners should generally be the last to start and first to > stop to avoid operating in an inconsistent state mostly combined with data > loss and SLA violations. > > Besides a note from Ruwan that task initialisation depends on listeners being > started before, I see no real reason to start the listeners that early. I > first trial to move them to a later point showed no problems for me (also I > did not test tasks). > > I definitely find it important to clarify the whole startup/shutdown logic > including the Axis2 module aspect, where I can't provide any useful feedback, > before releasing 1.3. > > Regards, > Eric > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
