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 Fri, 03 Apr 2009 20:56:06 GMT
Hi,

 

Ruwan, to me this sounds like a move into the right direction.
Unfortunately I don't have the initialization code fully memorized so
it's not that easy to follow the thoughts in a FLIESSTEXT.

Comparing to sequence diagrams would be something my brain could easily
catch. Anyway I initially posted a method sequence. So what I would like
to do first is repeat the current situation before showing my
understanding of you proposed change. Please correct if I got something
wrong!

 

a) current startup flow

 

1 SynapseServer.main()

 

1.1
ServerConfigurationInformationFactory.createServerConfigurationInformati
on(args);

 

1.2 ServerManager.getInstance();

 

1.3 ServerManager.init()

1.3.1
SynapseControllerFactory.createSynapseController(configurationInformatio
n);

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.2 create and Init Listener Manager

1.3.2.1.3 add and start transports <--- this looks terribly wrong

1.3.2.2 Axis2SynapseController.initDefaults()

1.3.2.2.1
Axis2SynapseController.addDefaultBuildersAndFormatters(configurationCont
ext.getAxisConfiguration());

1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions();

1.3.2.2.3 Axis2SynapseController.setupDataSources();

 

1.4 ServerManager.start()

1.4.1 ServerManager.assertInitialized()

1.4.2 ServerManager.doInit()

1.4.3 ServerManager.doStart()

1.4.3.1 Axis2SynapseController.createSynapseConfiguration();

1.4.3.2 Axis2SynapseController.createSynapseEnvironment();

1.4.3.2.1 Axis2SynapseController.setupSynapse()

1.4.3.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties();

1.4.3.2.1.2 Axis2SynapseController.setupMainMediation();

1.4.3.2.1.3 Axis2SynapseController.setupProxyServiceMediation();

1.4.3.2.1.4 Axis2SynapseController.setupEventSources();

1.4.3.2.2 SynapseConfiguration.init()

1.4.4.2.2.init registry, init endpoints, init managed mediators, init
proxies, init startup tasks, 

 

b) proposed startup flow

 

1 SynapseServer.main()

 

1.1
ServerConfigurationInformationFactory.createServerConfigurationInformati
on(args);

 

1.2 ServerManager.getInstance();

 

1.3 ServerManager.init()

1.3.1
SynapseControllerFactory.createSynapseController(configurationInformatio
n);

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.2 create and Init Listener Manager

1.3.2.1.3 add transports without starting them

1.3.2.2 Axis2SynapseController.initDefaults()

1.3.2.2.1
Axis2SynapseController.addDefaultBuildersAndFormatters(configurationCont
ext.getAxisConfiguration());

1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions();

1.3.2.2.3 Axis2SynapseController.setupDataSources();

 

1.4 ServerManager.start()

1.4.1 ServerManager.assertInitialized()

1.4.2 ServerManager.doInit()

1.4.3 ServerManager.doStart()

1.4.3.1 Axis2SynapseController.createSynapseConfiguration();

1.4.3.2 Axis2SynapseController.createSynapseEnvironment();

1.4.3.2.1 Axis2SynapseController.setupSynapse()

1.4.3.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties();

1.4.3.2.1.2 Axis2SynapseController.setupMainMediation();

1.4.3.2.1.3 Axis2SynapseController.setupProxyServiceMediation();

1.4.3.2.1.4 Axis2SynapseController.setupEventSources();

1.4.3.2.2 SynapseConfiguration.init()

1.4.3.2.2.1 init registry, init endpoints, init managed mediators, init
proxies

1.4.3.3 Axis2SynapseController.start() <-- add to interface

1.4.3.3.1 start Listener Manager which in turn start all registered
transports

1.4.3.3.2 init startup tasks

 

Does this correctly reflect your idea Ruwan?

 

What about this slight modification?

 

1 SynapseServer.main()

 

1.1
ServerConfigurationInformationFactory.createServerConfigurationInformati
on(args);

 

1.2 ServerManager.getInstance();

 

1.3 ServerManager.init()

1.3.1
SynapseControllerFactory.createSynapseController(configurationInformatio
n);

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.2 create and Init Listener Manager

1.3.2.1.3 add transports without starting them

1.3.2.2 Axis2SynapseController.initDefaults()

1.3.2.2.1
Axis2SynapseController.addDefaultBuildersAndFormatters(configurationCont
ext.getAxisConfiguration());

1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions();

1.3.2.2.3 Axis2SynapseController.setupDataSources();

 

1.4 ServerManager.start()

1.4.1 ServerManager.assertInitialized()

1.4.2 ServerManager.doInit()

1.4.3 ServerManager.doStart()

1.4.3.1 Axis2SynapseController.preStart() <-- add to interface

1.4.3.1.1 Axis2SynapseController.createSynapseConfiguration(); <--
remove from interface, protected

1.4.3.1.2 Axis2SynapseController.createSynapseEnvironment(); <-- remove
from interface, protected

1.4.3.1.2.1 Axis2SynapseController.setupSynapse()

1.4.3.1.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties();

1.4.3.1.2.1.2 Axis2SynapseController.setupMainMediation();

1.4.3.1.2.1.3 Axis2SynapseController.setupProxyServiceMediation();

1.4.3.1.2.1.4 Axis2SynapseController.setupEventSources();

1.4.3.1.2.2 SynapseConfiguration.init()

1.4.3.1.2.2.1 init registry, init endpoints, init managed mediators,
init proxies

1.4.3.2 Axis2SynapseController.start() <-- add to interface

1.4.3.2.1 start Listener Manager which in turn start all registered
transports

1.4.3.3 Axis2SynapseController.postStart() <-- add to interface

1.4.3.3.1 start tasks

 

Regarding the question whether to extend the existing ManagedLifecycle
interface or using a new one, I'm not sure whether I understand the
reasoning. What would be the benefit for a managed mediator to know when
the listener is started? Any implementor would need to provide an
implementation. Not sure if this makes sense. Please also remember that
there is already an interface called Startup extending ManagedLifecycle!

 

Ah, now I think I got your point you think of splitting the current
implementation of SimpleQuartz.init() in .init() and start() calling the
init() as we are doing it now from SynapseConfiguration.init() and
calling the start() after start of the listeners. Then we could also
only add start() to the Startup interface. Any implementor needing this
callback could choose to implement Startup instead of ManagedLifecycle.
I would prefer this to adding the method to MangedLifecycle directly.

 

Yes, after thinking a bit about it I'm +1 on your suggestion.

 

Other thoughts?

 

Regards,

   Eric

________________________________

From: Ruwan Linton [mailto:ruwan.linton@gmail.com] 
Sent: Friday, April 03, 2009 12:45 PM
To: dev@synapse.apache.org
Subject: Re: startup order - correct place to start transport listeners

 

Here is my proposal,

We introduce a start method to the SynapseController so that we can init
the Axis2 environment in the init method of the controller and then
initialize the Synapse environment after creating the
SynapseConfiguration and call this introducing start method.

init method of the controller initializes the listener manager and add
all the listeners parsing true to not to start the listeners upon adding
them to the listener manager.

In the start method we start the listener manager which intern will
start all the listeners.

Further, post starting tasks like starting the Tasks and so on has to be
handled with a different call after the start call. We may come up with
a different interface for these or introduce a method to the
ManagedLifecycle interface called start, apart from the init and destroy
methods so that the start method will be called after starting the
listener manager, from the ServerManager class.

This resolves the issue...

WDYT?

Thanks,
Ruwan

On Fri, Apr 3, 2009 at 3:19 PM, Hubert, Eric <Eric.Hubert@foxmobile.com>
wrote:

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.

 

Ruwan, I fully agree. While reading the dev list I noticed quite often
that the final result of a discussed solution profited a lot from
valuable input of other developers. For me this is simply a combined
(team) strength which could be used even more actively.

 

Regards,

   Eric

 




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