synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <Eric.Hub...@foxmobile.com>
Subject RE: startup order - correct place to start transport listeners
Date Wed, 08 Apr 2009 13:25:38 GMT
Thanks Ruwan! Your changes to the startup look straightforward and correct to me.

 

Current startup order after you change reads as follows (main changes are bold):

 

1 SynapseServer.main()

 

1.1 ServerConfigurationInformationFactory.createServerConfigurationInformation(args);

 

1.2 ServerManager.getInstance();

 

1.3 ServerManager.init()

1.3.1 SynapseControllerFactory.createSynapseController(configurationInformation);

1.3.2 ServerManager.doInit()

1.3.2.1 Axis2SynapseController.init()

1.3.2.1.1 Axis2SynapseController.createNewInstance()

1.3.2.1.1.1 Axis2SynapseController.createConfigurationContextFromFileSystem()

1.3.2.1.1.2 create and Init Listener Manager, but do not start

1.3.2.2 Axis2SynapseController.initDefaults(ServerContextInformation)

1.3.2.2.1 Axis2SynapseController.addDefaultBuildersAndFormatters(configurationContext.getAxisConfiguration());

1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions();

1.3.2.2.3 Axis2SynapseController.setupDataSources();

1.3.2.2.4 setupTaskHelper(contextInformation);

 

1.4 ServerManager.start()

1.4.1 ServerManager.assertInitialized()

1.4.2 ServerManager.doStart()

1.4.2.1 Axis2SynapseController.createSynapseConfiguration();

1.4.2.2 Axis2SynapseController.createSynapseEnvironment();

1.4.2.2.1 Axis2SynapseController.setupSynapse()

1.4.2.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties();

1.4.2.2.1.2 Axis2SynapseController.setupMessageMediation();

1.4.2.2.1.3 Axis2SynapseController.setupProxyServiceMediation();

1.4.2.2.1.4 Axis2SynapseController.setupEventSources();

1.4.2.2.2 SynapseConfiguration.init()

1.4.2.2.2.1 init registry, init endpoints, init managed mediators, init proxies, init startups

1.4.2.3 Axis2SynapseController.start()

1.4.2.3.1 start Listener Manager which in turn starts all registered transports

 

 

Also the complete shutdown logic has been restructured and corrected:

 

For the case the server is started:

1 ShutdownHook

1.1 ServerManager.stop()

1.1.1 ServerManager.doStop()

1.1.1.1 Axis2SynapseController.stop()

1.1.1.1.1 Axis2SynapseController.cleanupDefault()

1.1.1.1.1.1 remove task descriptions and shutdown task scheduler

1.1.1.1.2 stop transports

1.1.1.1.3 deactivate services

1.1.1.1.4 shutdown Axis2 modules

1.1.1.2 Axis2SynapseController.destroySynapseEnvironment();

1.1.1.3 Axis2SynapseController.destroySynapseConfiguration();

1.1.1.3.1 SynapseConfiguration.destroy()

1.1.1.3.1.1 stop timer, destroy proxies, destroy sequences, destroy endpoints, destroy, startups,
shutdown startup task scheduler, clear RMI registry

1.2 ServerManager.destroy()

1.2.1 ServerManager.doDestroy()

1.2.1.1 Axis2SynapseController.destroy()

1.1.2.1.1 destroy Listener Manager

1.1.2.1.2 ConfigurationContext.terminate()

 

 

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()?

2)       Why is destroy public? Why does stop() not call doDestroy() directly? Answer to 1)
may already answer this.

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

 

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.

 

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.

 

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 

Mime
View raw message