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 Wed, 08 Apr 2009 15:06:34 GMT
Hi Eric,

The steps you have listed are correct and please note that the ServerManager
has been now instrumented with the following sequence of life cycle methods
and I have realized that at least for now we do not need this same method
structure on the ManagedLifecycle interface.

ServerManager#init()
ServerManager#start()
ServerManager#stop()
ServerManager#destroy()

If you look for the state transition it is as shown in this diagram.

Please see my answers in line;

> Please let me ask a couple of small questions for my understanding.
>
>
>
> 1)       Who shall call destroy() on ServerManager? (Only the shutdown
> hook defined in SynapseServer after calling stop()?) Or was it originally
> meant that destroy is called instead of stop()?
>
Well stop and destroy are two operations, once you stop you may again start
the server without initializing the server, where as if you call destroy the
server has to be reinitialized to start. In contrast if you call destroy
while the state is being ServerState.STARTED we first stop the server and
then destroy it.

> 2)       Why is destroy public? Why does stop() not call doDestroy()
> directly? Answer to 1) may already answer this.
>
I think the answer above explains why I did it like this. Even though from
the code that we have right now it seem like we could merge these two, in
order to properly manage the states and keeping the room for any
extensibility on the shutdown process, I implemented it like this. If you
look at the shutdown process now, it is the exact opposite of the start
order which has to be the case.

> 3)       What is the relation of the task_scheduler and
> synapse.startup.taskscheduler (TaskConstants/SynapseConstants)? So far I had
> no contact with tasks at all. I’m only a bit confused about to places where
> some schedulers are going to be destroyed:
> Axis2SynapseController.cleanupDefault() and SynapseConfiguration.destroy()
>
Good point, there seems to be some further improvements to the task
scheduling logic... the references that you pointed does the same and we
should get rid of one. I think it has to be the cleanupDefaults keeping the
destroying process in the SynapseConfig#destroy

>
>
> Regarding the shutdown order I’m still not quite sure whether it is
> entirely correct. The position of start and stop of listeners seems to be
> correct, though. I’m wondering why SynapseConfiguration.destroy() is called
> rather late. I would have expected it to be called even before
> Axis2SynapseController.destroySynapseEnvironment(), but I have had no time
> to think about the reasoning.
>
We could change the order of these two.

>
>
> Maybe you concentrated on the startup and did only some changes to the
> shutdown process. I will be able to take more than just a few minutes at the
> weekend. I just wanted to give a quick feedback on your efforts which are
> highly appreciated.
>
Thanks, I think apart from the above swap it is OK, I highly concentrated on
the shutdown order as well, and even had to get the Axis2 Listener Manager
fixed to support this scenario.

Thanks,
Ruwan

>
>
> Regards,
>
>    Eric
>
>
>   ------------------------------
>
> *From:* Ruwan Linton [mailto:ruwan.linton@gmail.com]
> *Sent:* Tuesday, April 07, 2009 10:20 PM
> *To:* dev@synapse.apache.org
> *Subject:* Re: startup order - correct place to start transport listeners
>
>
>
> committed the first cut and open for review :-)
>
> Thanks,
> Ruwan
>
> On Tue, Apr 7, 2009 at 7:05 PM, Ruwan Linton <ruwan.linton@gmail.com>
> wrote:
>
> I've completed most of the implementation of the first cut... and waiting
> on this fix [1] in axis2 to make it 100% accurate. :-)
>
> Thanks,
> Ruwan
>
> [1] - https://issues.apache.org/jira/browse/AXIS2-4304
>
>
>
> On Mon, Apr 6, 2009 at 10:18 PM, Ruwan Linton <ruwan.linton@gmail.com>
> wrote:
>
> I am in the process of implementing this....
>
> I found a few issues and had to take a few decisions.
>
> Issues :- The existing approach doesn't prevent messages to be flowing into
> synapse before deploying proxies and so on, because the message interception
> handlers are attached through the module while the synapse initialization is
> handled out of the module initialization.
>
> I found it impossible to implement the listener manager initialization and
> startup to be different, even though I was planing to do so.
>
> Decisions :- Add the start and stop methods to the ManagedLifecycle
> No need of an post start method to the controller, but inside the
> controller.start, call the ManagedLifecycle.start()
>
> Will be able to commit the first cut soon.
>
> Thanks,
> Ruwan
>
>
>
> On Mon, Apr 6, 2009 at 9:39 AM, indika kumara <indika.kuma@gmail.com>
> wrote:
>
> Ruwan
>
> I never said that suggested approach is bad. if you have confidence
> that approach will work , then it is good . Generally , a problem have
> many solutions. I just say what I like.
> You will go on your way. If it can achieve what we need , then it is a
> good solution.
>
> Thanks
> Indika
>
>
> On Sun, Apr 5, 2009 at 3:07 PM, Ruwan Linton <ruwan.linton@gmail.com>
> wrote:
> > Indika,
> >
> > If we are going for such a change it has to go into axis2 and I think it
> is
> > late to get this to axis2 1.5, and I think this is much cleaner.... can
> you
> > point any issue with this approach? Any reasoning to not to add a start
> > method....
> >
> > Thanks,
> > Ruwan
> >
> > On Sun, Apr 5, 2009 at 12:24 PM, indika kumara <indika.kuma@gmail.com>
> > wrote:
> >>
> >> Runwan
> >>
> >> I personally like, if there are some fixes need to be done on
> >> transport layer, if it could be done.
> >>
> >> BTW, it is good if we can cope (by the implementation we are going to
> >> do) transparently with current and future behaviors of transports as
> >> synapse always operate top on that.
> >>
> >> Thanks
> >> Indika
> >>
> >> On Sun, Apr 5, 2009 at 11:33 AM, Ruwan Linton <ruwan.linton@gmail.com>
> >> wrote:
> >> > Indika,
> >> >
> >> > I think having a start method is much cleaner than this, because
> >> >
> >> > listener manager doesn't support adding the transport in the
> maintenance
> >> > mode...
> >> > if we try to start and then put the transport into the maintenance
> mode
> >> > even
> >> > then there is a time where the transports are exposed to the external
> >> > users
> >> > before synapse initialization
> >> > Not all the transports support maintenance mode
> >> >
> >> > So I would go with the above proposed approach, which is much cleaner.
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Sun, Apr 5, 2009 at 10:57 AM, indika kumara <indika.kuma@gmail.com
> >
> >> > wrote:
> >> >>
> >> >> Hi All
> >> >>
> >> >> I am not sure but could we achieve following event sequence?
> >> >>
> >> >> Initializing…………….
> >> >>
> >> >> Initialized and start transport on graceful mode
> >> >> Create synapse configuration
> >> >> Create synapse environment
> >> >> Initialized synapse configuration
> >> >> Change the mode of listeners to fully active
> >> >>
> >> >> Shouting down ……………….
> >> >>
> >> >> Signal to change the mode of transport into graceful
> >> >> destroy synapse configuration and synapse environment
> >> >> Signal to completely destroy transport
> >> >>
> >> >> Could we achieve what we need with above order sequence of events?
If
> >> >> it can, I feel we never want to change any API.
> >> >>
> >> >> 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
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
> ---------------------------------------------------------------------
> 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
>
>
>
>   --
>
> 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
>
>
>
>
> --
> 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
>



-- 
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