synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: startup order - correct place to start transport listeners
Date Fri, 03 Apr 2009 06:10:55 GMT
Indika,

I agree with you, but what we are considering is the same as this
explanation. We do not want to kept the listener initialization till we
initialize rest of the components. For the moment what happens is basically,
while we initialize the components messages can flow into these components
because the listeners are already started to accept the messages, which is
completely wrong because the initialization of the application layer is
halfway through.

So this is a matter of clearly differentiating the initialization from the
starting process. So even though the listeners are initialized they
shouldn't accept messages till the application layer (i.e. components or the
Synapse Env) signals the ready state.

I am trying to come up with a proposal to implement this. When we do a
considerable change, it is better to discuss things before commiting to
implement that even though we are operating on CTR model.

Thanks,
Ruwan

On Fri, Apr 3, 2009 at 11:02 AM, indika kumara <indika.kuma@gmail.com>wrote:

> Hi all
>
> I didn’t care much about stop order. It’s my wrong. Thanks for correcting
> it.
>
> But, I strongly feel, what need is correct implementation of graceful
> start and shutdown semantic and integrate it.
>
> When build a something top on a based - a layered approach.
>
> Initializing process is going upward and showdown process is going
> downward. When creating a layer top on another layer, base layer
> should not call any functions on currently being building uppperlayer
> but should allow downward call from upper layer. Only after correctly
> build the upper layer, upward channel should open.
>
> Shutdown process should begin with signaling lower layers to cutoff
> the upward channel and but accept downward calls. Only, after
> completely has been showdown upper layer, down layer should cutoff
> downward channel.  Destroying base layer at first is bad solution.
>
> Considering synapse is in application layer and transport handling
> components is in transport layer.  Initialization should begin with
> transport layer. On initialization, the transport layer should not
> accept any requests received (cutoff upward channel) and call
> functions in application layer, until application layer components
> tell (by event) that open upward channel. But, downward channel should
> be opened at anytime. In shutdown process, application should tell
> transport to change the mode so that cutoff upward channel but remain
> open downward and then begin to properly showdown application
> components and only after that tell transport to cutoff downward
> channel and to make shutdown complete.
>
> Only a solution that implement semantic such as above will work.
> Solutions without semantic are definitely tricks.
>
> I can remind, there was a trick to cope with early start of listeners.
> Synapse configuration (endpoint , proxy , startup , endpoint, etc) was
> initialized with synapse environment that have set to initialized
> ‘false’ and then start listeners and then set synapse environment to
> initialized ‘true’ and call ‘startup’ initialization. This only shows
> a design flaws. If proper initialization semantic was preserved
> (during initialization top layer can talk (can request) to down layer
> but down layer cannot talk (no request) to upper layer), this kind of
> trick that something get to work was really not needed.
>
> Calling listener showdown before applications components are shutting
> down, is bad solution. If the transport has been shut down, what if
> any application component that still ruing is needed transport - for
> example running task …Anyway destroying base before components top on
> base is bad design principle.  Here, graceful showdown semantic of
> system (not just transport) has not been preserved. Shutting down
> should begin with notifying base that I am going to shutdown so that
> base can cut off upward channel (transport doesn’t accept new request
> and but accept results from applications )) but remain open the
> downward channel. Then, application can safely shout down. After
> completing shutdown, it can notify base to cutoff the down channel and
> complete shut down.
>
> For a sophisticate graceful start and shutdown semantic, components
> relationship within any layers may need to include. (What if a
> sequence is referred by another sequence and that reference sequence
> has been destroying while it is being used.)
>
> Anything without semantic is a trick - something I never like.
>
> Thanks
> Indika
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message