synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From indika kumara <>
Subject Re: startup order - correct place to start transport listeners
Date Tue, 31 Mar 2009 07:39:42 GMT

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.


On Tue, Mar 31, 2009 at 11:13 AM, Hubert, Eric
<> 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:
For additional commands, e-mail:

View raw message