synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: startup order - correct place to start transport listeners
Date Tue, 31 Mar 2009 08:12:05 GMT
Isn't there a substantial difference in initialization and the actual start?
I have absolutely nothing to argue against a proper initialization of the Axis2 subsystem.

If I do not misunderstand the current code, Synapse has not only control about the time the
listeners are initialized but also when they are actually started. 

Calling ListenerManager.init() (initialization) is not the same as adding a non-started listener
to the manager and letting it start.

I guess the whole Axis2 environment is properly initialized without starting a single listener.
Of course this has to be done before you want to process the first request. But this time
exactly depends on the need of the environment which embeds Axis2. In our case only once Synapse
is fully initialized it is safe to ask the Axis2 engine to start-up the listeners.

Any other solution would from my point of view only introduce additional complexity and possibilities
to break without adding value besides a more academically separation of concerns.

What do others think about it?


> -----Original Message-----
> From: indika kumara []
> Sent: Tuesday, March 31, 2009 9:40 AM
> To:
> Subject: Re: startup order - correct place to start transport listeners
> 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
> <> 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