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: [email protected] For additional commands, e-mail: [email protected]
