You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Hubert, Eric" <Er...@foxmobile.com> on 2009/03/28 21:08:39 UTC
startup order - correct place to start transport listeners
Hi all,
while working on patch to make direct use of the existing MBeans in Synapse I was wondering about the current order of actions during Synapse startup.
If I'm not wrong it looks like the transports are started somewhere in the middle of the Synapse startup. Is this observation correct? Is this on purpose? Too me this looks like a serious error.
The listeners should be started only once the whole configuration process has been successfully finished. Otherwise traffic would be accepted even though the initialization of the configuration (proxies, sequences, endpoints and so on) may fail.
Here is what I have read from the code (standalone deployment):
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.2 create and Init Listener Manager
1.3.2.1.3 start transports <--- this looks terribly wrong
1.3.2.2 Axis2SynapseController.initDefaults()
1.3.2.2.1 Axis2SynapseController.addDefaultBuildersAndFormatters(configurationContext.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()
--> up to this point a lot of errors can occur resulting in "Synapse startup failed"
Why don't we start listeners only if we reach this point without an error?
I would propose to start the listeners immediately before the log output:
ServerManager - Ready for processing
Is there anything which will prevent this to work? If not I would be willing to work on a patch.
So far I didn't test those hypotheses, so I may be wrong. Please feel to correct my current understanding!
Regards,
Eric
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Isn't there a substantial difference in initialization and the actual start?
I have absolutely nothing to argue against a proper initialization of the Axis2 subsystem.
If I do not misunderstand the current code, Synapse has not only control about the time the listeners are initialized but also when they are actually started.
Calling ListenerManager.init() (initialization) is not the same as adding a non-started listener to the manager and letting it start.
I guess the whole Axis2 environment is properly initialized without starting a single listener. Of course this has to be done before you want to process the first request. But this time exactly depends on the need of the environment which embeds Axis2. In our case only once Synapse is fully initialized it is safe to ask the Axis2 engine to start-up the listeners.
Any other solution would from my point of view only introduce additional complexity and possibilities to break without adding value besides a more academically separation of concerns.
What do others think about it?
Regards,
Eric
> -----Original Message-----
> From: indika kumara [mailto:indika.kuma@gmail.com]
> Sent: Tuesday, March 31, 2009 9:40 AM
> To: dev@synapse.apache.org
> Subject: Re: startup order - correct place to start transport listeners
>
> Hi
>
> What I was done is simply make sure that synapse stared only if
> underlying environment has stared property.
>
> If the listeners are belonged to axis2 (I believe it is an abstraction
> related with axis2 architecture - design decision), initialization of
> those should be done by axis2 as it is the only one responsible for
> enforcing semantic of its abstractions. Therefore, if the axis2 say
> that it has been started properly, we have to trust it. We always need
> to preserve semantic which say synapse will be only started if
> underlying environment has been stared.
>
> I agree on effects of system down time, but I cannot agree on staring
> listeners after synapse as a solution. If the listeners part of axis2
> , axis2 should do that.
>
> If it is needed to preserve the delivery guarantee (delivering message
> to synapse), best solution may be the message queuing (persistence
> communication) at transport (axis2) level. It cannot validate how much
> this difficult or any issues. But this is the solution many system
> use. Other solution may be failure model for receive omission with
> notification failure. This is any way currently happening if any
> message is came before starting listeners (By sending transport level
> error messages). We can apply same concept by sending error indicating
> synapse is not ready (may be mapping error to http or any application
> level protocol or soap fault) so that client can retry.
>
> Thanks
> Indika
>
> On Tue, Mar 31, 2009 at 11:13 AM, Hubert, Eric
> <Er...@foxmobile.com> wrote:
> > Hi all,
> >
> > unfortunately at the moment I'm still not able to help much with this
> discussion as I did not spend enough time to understand the coupling of
> Axis2 and Synapse in detail.
> >
> > Generally what Indika writes about the decoupling of transports and
> mediation engine makes definitely sense from my high level view.
> >
> > The only point where I disagree is the startup of listeners. It seems
> impossible to me "to compensate" broken requests.
> > In any system listeners should generally be the last to start and first
> to stop to avoid operating in an inconsistent state mostly combined with
> data loss and SLA violations.
> >
> > Besides a note from Ruwan that task initialisation depends on listeners
> being started before, I see no real reason to start the listeners that
> early. I first trial to move them to a later point showed no problems for
> me (also I did not test tasks).
> >
> > I definitely find it important to clarify the whole startup/shutdown
> logic including the Axis2 module aspect, where I can't provide any useful
> feedback, before releasing 1.3.
> >
> > Regards,
> > Eric
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
Hi
What I was done is simply make sure that synapse stared only if
underlying environment has stared property.
If the listeners are belonged to axis2 (I believe it is an abstraction
related with axis2 architecture - design decision), initialization of
those should be done by axis2 as it is the only one responsible for
enforcing semantic of its abstractions. Therefore, if the axis2 say
that it has been started properly, we have to trust it. We always need
to preserve semantic which say synapse will be only started if
underlying environment has been stared.
I agree on effects of system down time, but I cannot agree on staring
listeners after synapse as a solution. If the listeners part of axis2
, axis2 should do that.
If it is needed to preserve the delivery guarantee (delivering message
to synapse), best solution may be the message queuing (persistence
communication) at transport (axis2) level. It cannot validate how much
this difficult or any issues. But this is the solution many system
use. Other solution may be failure model for receive omission with
notification failure. This is any way currently happening if any
message is came before starting listeners (By sending transport level
error messages). We can apply same concept by sending error indicating
synapse is not ready (may be mapping error to http or any application
level protocol or soap fault) so that client can retry.
Thanks
Indika
On Tue, Mar 31, 2009 at 11:13 AM, Hubert, Eric
<Er...@foxmobile.com> wrote:
> Hi all,
>
> unfortunately at the moment I'm still not able to help much with this discussion as I did not spend enough time to understand the coupling of Axis2 and Synapse in detail.
>
> Generally what Indika writes about the decoupling of transports and mediation engine makes definitely sense from my high level view.
>
> The only point where I disagree is the startup of listeners. It seems impossible to me "to compensate" broken requests.
> In any system listeners should generally be the last to start and first to stop to avoid operating in an inconsistent state mostly combined with data loss and SLA violations.
>
> Besides a note from Ruwan that task initialisation depends on listeners being started before, I see no real reason to start the listeners that early. I first trial to move them to a later point showed no problems for me (also I did not test tasks).
>
> I definitely find it important to clarify the whole startup/shutdown logic including the Axis2 module aspect, where I can't provide any useful feedback, before releasing 1.3.
>
> Regards,
> Eric
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi all,
unfortunately at the moment I'm still not able to help much with this discussion as I did not spend enough time to understand the coupling of Axis2 and Synapse in detail.
Generally what Indika writes about the decoupling of transports and mediation engine makes definitely sense from my high level view.
The only point where I disagree is the startup of listeners. It seems impossible to me "to compensate" broken requests.
In any system listeners should generally be the last to start and first to stop to avoid operating in an inconsistent state mostly combined with data loss and SLA violations.
Besides a note from Ruwan that task initialisation depends on listeners being started before, I see no real reason to start the listeners that early. I first trial to move them to a later point showed no problems for me (also I did not test tasks).
I definitely find it important to clarify the whole startup/shutdown logic including the Axis2 module aspect, where I can't provide any useful feedback, before releasing 1.3.
Regards,
Eric
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Andreas,
This will work for all the transports, but it makes most sense to the HTTP
and HTTPS transports, because we are managing those two transports where as
a third party is managing most of the other transports while we provide a
connector to the respective transport in other cases.
If you look at the way most of the other transports work, the actual binding
happens with the service, and until you call startListeningForService the
transport will not be active for that particular service, this will be
called at the start method.
If you tries to send a JMS message to a service while synapse is down, it is
anyway not going to come onto the synapse layer, rather it will be queued in
the JMS provider till we start. So once we start if we accept messages
before initializing the synapse environment, (this is what happens now) the
messages which are queued in the JMS provider layer will come into synapse
before the mediators are completed in initialization. So it is wrong, but in
the proposed implementation we call the TrpLstner#start after initializing
the SynapseEnv, so that will intern call startLstningForSvc, and by that
time SynapseEnv is completely initialize and ready to process.
Same scenario will be applied to most of the other polling transports.
Thanks,
Ruwan
On Sat, Apr 4, 2009 at 4:39 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Ruwan,
>
> Can you cite any transport other than HTTP(S) with which that would
> actually work?
>
> Andreas
>
> On Thu, Apr 2, 2009 at 14:53, Ruwan Linton <ru...@gmail.com> wrote:
> > Well, we had two operation models called proxy service mediation and
> message
> > mediation. In the earlier case message is going to be dispatched to the
> > respective proxy service where as in the later case message will be
> directed
> > to the main sequence. Now the message mediation operational model is only
> > available for the HTTP/S
> >
> > From my POV this is conceptually wrong with the initial design of
> synapse.
> > Do we want to drop in the message mediation.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Apr 2, 2009 at 1:35 PM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> I guess the HTTP(S) restriction is there for the case where Synapse is
> >> used as an HTTP proxy. I don't see how we would get a similar behavior
> >> with any other transport, so this actually looks right (but should be
> >> better documented in the code).
> >>
> >> Andreas
> >>
> >> On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ru...@gmail.com>
> wrote:
> >> > Yes, I fixed the handler module.... but what I am referring is the
> >> > normal
> >> > synapse behavior, not the handler module.
> >> >
> >> > For the message mediation case I think we shouldn't restrict the
> >> > transports.
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <in...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Runwan
> >> >>
> >> >> HTTP and HTTPS for synapse message mediation (_SynapseService)
> >> >> setting was there in the previous code (Proxy service only had the
> per
> >> >> service transports ) . I actually only did refractor - cut and paste
> >> >> and change only organization. Synapse as Handler module can be
> >> >> deployed without much effort... may three , four line ........
> >> >>
> >> >> Thanks
> >> >> Indika
> >> >>
> >> >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ruwan.linton@gmail.com
> >
> >> >> wrote:
> >> >> > I went through the new synapse startup logic and it seems OK but
> this
> >> >> > makes
> >> >> > the following concrete changes to the synapse architecture
> >> >> >
> >> >> > Synapse can no longer be deployed just as a pure module in axis2,
> it
> >> >> > requires much more work.
> >> >> > The message mediation is restricted to HTTP and HTTPS, which I am
> not
> >> >> > sure
> >> >> > whether we want to keep it as it is.
> >> >> >
> >> >> > But still this new logic even doesn't address the original problem
> in
> >> >> > the
> >> >> > discussion. In the new logic transport listeners starts even before
> >> >> > the
> >> >> > mediators getting loaded into synapse.
> >> >> >
> >> >> > I think we need to improve this, and to me Eric's point is
> completely
> >> >> > a
> >> >> > valid point. I will further look into resolving this and will keep
> >> >> > the
> >> >> > list
> >> >> > posted.
> >> >> >
> >> >> > Thanks,
> >> >> > Ruwan
> >> >> >
> >> >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva
> >> >> > <su...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi Indika,
> >> >> >>
> >> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara
> >> >> >> <in...@gmail.com>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> If the synapse is run top on axis2 or any other, it should be
> >> >> >>> properly
> >> >> >>> initialized and started before initialize synapse.
> >> >> >>
> >> >> >>
> >> >> >> We are talking about two things here. Initialization and startup.
> I
> >> >> >> agree
> >> >> >> synapse should inilialize after axis2. Also Synapse should start
> >> >> >> after
> >> >> >> Axis2. But at the moment it seems that Synapse is starting even
> >> >> >> before
> >> >> >> it
> >> >> >> initializes. The way Synapse is written it is perfectly normal to
> >> >> >> assume
> >> >> >> that it is started when Axis2 is started. But if we do it in the
> >> >> >> current
> >> >> >> way, this assumption is broken and can lead to failures as Eric
> >> >> >> said.
> >> >> >> If
> >> >> >> Axis2 is initialize properly we can initialize Synapse. As Eric
> said
> >> >> >> if
> >> >> >> both
> >> >> >> are successfully initialized we can start Axis2 transports, which
> >> >> >> automatically starts Synapse.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Supun.
> >> >> >>
> >> >> >>
> >> >> >>>
> >> >> >>> It is a well known
> >> >> >>> semantic that system should be in consistent state before use it.
> >> >> >>> You
> >> >> >>> can refer [1] and it says why I did.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>>
> >> >> >>> The way message get in to synapse and mediation engine (main
> >> >> >>> behavior)
> >> >> >>> are two different aspects and definitely should have two
> different
> >> >> >>> decision designs as it is wrong if main behavior depend on other
> >> >> >>> behavior. The starting, shutdown --- simply state (consistent)
> >> >> >>> management of mediation should not depend any thing. Axis2
> Hander
> >> >> >>> is
> >> >> >>> make way to get message into in to synapse and for good design,
> >> >> >>> mediation engine should separate from this design decision.
> >> >> >>> Managing
> >> >> >>> mediation engine should be independent from axis2 or any other.
> >> >> >>>
> >> >> >>> If it is needed to avoid effect of started listeners if the
> synapse
> >> >> >>> mediation engine started up is failed, then only applicable
> >> >> >>> transaction semantic is compensation transaction. In order to
> >> >> >>> enforce
> >> >> >>> that, it is needed to properly shutdown listeners, etc --- some
> how
> >> >> >>> need to move into a consistent state before system startup.
> >> >> >>>
> >> >> >>> [1]
> >> >> >>> http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
> >> >> >>>
> >> >> >>> Thanks
> >> >> >>> Indika
> >> >> >>>
> >> >> >>>
> >> >> >>>
> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> >> >>> For additional commands, e-mail: dev-help@synapse.apache.org
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Software Engineer, WSO2 Inc
> >> >> >> http://wso2.org
> >> >> >> supunk.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
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
Re: startup order - correct place to start transport listeners
Posted by Andreas Veithen <an...@gmail.com>.
Ruwan,
Can you cite any transport other than HTTP(S) with which that would
actually work?
Andreas
On Thu, Apr 2, 2009 at 14:53, Ruwan Linton <ru...@gmail.com> wrote:
> Well, we had two operation models called proxy service mediation and message
> mediation. In the earlier case message is going to be dispatched to the
> respective proxy service where as in the later case message will be directed
> to the main sequence. Now the message mediation operational model is only
> available for the HTTP/S
>
> From my POV this is conceptually wrong with the initial design of synapse.
> Do we want to drop in the message mediation.
>
> Thanks,
> Ruwan
>
> On Thu, Apr 2, 2009 at 1:35 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> I guess the HTTP(S) restriction is there for the case where Synapse is
>> used as an HTTP proxy. I don't see how we would get a similar behavior
>> with any other transport, so this actually looks right (but should be
>> better documented in the code).
>>
>> Andreas
>>
>> On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ru...@gmail.com> wrote:
>> > Yes, I fixed the handler module.... but what I am referring is the
>> > normal
>> > synapse behavior, not the handler module.
>> >
>> > For the message mediation case I think we shouldn't restrict the
>> > transports.
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <in...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Runwan
>> >>
>> >> HTTP and HTTPS for synapse message mediation (_SynapseService)
>> >> setting was there in the previous code (Proxy service only had the per
>> >> service transports ) . I actually only did refractor - cut and paste
>> >> and change only organization. Synapse as Handler module can be
>> >> deployed without much effort... may three , four line ........
>> >>
>> >> Thanks
>> >> Indika
>> >>
>> >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ru...@gmail.com>
>> >> wrote:
>> >> > I went through the new synapse startup logic and it seems OK but this
>> >> > makes
>> >> > the following concrete changes to the synapse architecture
>> >> >
>> >> > Synapse can no longer be deployed just as a pure module in axis2, it
>> >> > requires much more work.
>> >> > The message mediation is restricted to HTTP and HTTPS, which I am not
>> >> > sure
>> >> > whether we want to keep it as it is.
>> >> >
>> >> > But still this new logic even doesn't address the original problem in
>> >> > the
>> >> > discussion. In the new logic transport listeners starts even before
>> >> > the
>> >> > mediators getting loaded into synapse.
>> >> >
>> >> > I think we need to improve this, and to me Eric's point is completely
>> >> > a
>> >> > valid point. I will further look into resolving this and will keep
>> >> > the
>> >> > list
>> >> > posted.
>> >> >
>> >> > Thanks,
>> >> > Ruwan
>> >> >
>> >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva
>> >> > <su...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Indika,
>> >> >>
>> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara
>> >> >> <in...@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> If the synapse is run top on axis2 or any other, it should be
>> >> >>> properly
>> >> >>> initialized and started before initialize synapse.
>> >> >>
>> >> >>
>> >> >> We are talking about two things here. Initialization and startup. I
>> >> >> agree
>> >> >> synapse should inilialize after axis2. Also Synapse should start
>> >> >> after
>> >> >> Axis2. But at the moment it seems that Synapse is starting even
>> >> >> before
>> >> >> it
>> >> >> initializes. The way Synapse is written it is perfectly normal to
>> >> >> assume
>> >> >> that it is started when Axis2 is started. But if we do it in the
>> >> >> current
>> >> >> way, this assumption is broken and can lead to failures as Eric
>> >> >> said.
>> >> >> If
>> >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said
>> >> >> if
>> >> >> both
>> >> >> are successfully initialized we can start Axis2 transports, which
>> >> >> automatically starts Synapse.
>> >> >>
>> >> >> Thanks,
>> >> >> Supun.
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> It is a well known
>> >> >>> semantic that system should be in consistent state before use it.
>> >> >>> You
>> >> >>> can refer [1] and it says why I did.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> The way message get in to synapse and mediation engine (main
>> >> >>> behavior)
>> >> >>> are two different aspects and definitely should have two different
>> >> >>> decision designs as it is wrong if main behavior depend on other
>> >> >>> behavior. The starting, shutdown --- simply state (consistent)
>> >> >>> management of mediation should not depend any thing. Axis2 Hander
>> >> >>> is
>> >> >>> make way to get message into in to synapse and for good design,
>> >> >>> mediation engine should separate from this design decision.
>> >> >>> Managing
>> >> >>> mediation engine should be independent from axis2 or any other.
>> >> >>>
>> >> >>> If it is needed to avoid effect of started listeners if the synapse
>> >> >>> mediation engine started up is failed, then only applicable
>> >> >>> transaction semantic is compensation transaction. In order to
>> >> >>> enforce
>> >> >>> that, it is needed to properly shutdown listeners, etc --- some how
>> >> >>> need to move into a consistent state before system startup.
>> >> >>>
>> >> >>> [1]
>> >> >>> http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
>> >> >>>
>> >> >>> Thanks
>> >> >>> Indika
>> >> >>>
>> >> >>>
>> >> >>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Software Engineer, WSO2 Inc
>> >> >> http://wso2.org
>> >> >> supunk.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
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Well, we had two operation models called proxy service mediation and message
mediation. In the earlier case message is going to be dispatched to the
respective proxy service where as in the later case message will be directed
to the main sequence. Now the message mediation operational model is only
available for the HTTP/S
>From my POV this is conceptually wrong with the initial design of synapse.
Do we want to drop in the message mediation.
Thanks,
Ruwan
On Thu, Apr 2, 2009 at 1:35 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I guess the HTTP(S) restriction is there for the case where Synapse is
> used as an HTTP proxy. I don't see how we would get a similar behavior
> with any other transport, so this actually looks right (but should be
> better documented in the code).
>
> Andreas
>
> On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ru...@gmail.com> wrote:
> > Yes, I fixed the handler module.... but what I am referring is the normal
> > synapse behavior, not the handler module.
> >
> > For the message mediation case I think we shouldn't restrict the
> transports.
> >
> > Thanks,
> > Ruwan
> >
> > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <in...@gmail.com>
> wrote:
> >>
> >> Hi Runwan
> >>
> >> HTTP and HTTPS for synapse message mediation (_SynapseService)
> >> setting was there in the previous code (Proxy service only had the per
> >> service transports ) . I actually only did refractor - cut and paste
> >> and change only organization. Synapse as Handler module can be
> >> deployed without much effort... may three , four line ........
> >>
> >> Thanks
> >> Indika
> >>
> >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ru...@gmail.com>
> >> wrote:
> >> > I went through the new synapse startup logic and it seems OK but this
> >> > makes
> >> > the following concrete changes to the synapse architecture
> >> >
> >> > Synapse can no longer be deployed just as a pure module in axis2, it
> >> > requires much more work.
> >> > The message mediation is restricted to HTTP and HTTPS, which I am not
> >> > sure
> >> > whether we want to keep it as it is.
> >> >
> >> > But still this new logic even doesn't address the original problem in
> >> > the
> >> > discussion. In the new logic transport listeners starts even before
> the
> >> > mediators getting loaded into synapse.
> >> >
> >> > I think we need to improve this, and to me Eric's point is completely
> a
> >> > valid point. I will further look into resolving this and will keep the
> >> > list
> >> > posted.
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <
> supun06@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Indika,
> >> >>
> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <
> indika.kuma@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> If the synapse is run top on axis2 or any other, it should be
> properly
> >> >>> initialized and started before initialize synapse.
> >> >>
> >> >>
> >> >> We are talking about two things here. Initialization and startup. I
> >> >> agree
> >> >> synapse should inilialize after axis2. Also Synapse should start
> after
> >> >> Axis2. But at the moment it seems that Synapse is starting even
> before
> >> >> it
> >> >> initializes. The way Synapse is written it is perfectly normal to
> >> >> assume
> >> >> that it is started when Axis2 is started. But if we do it in the
> >> >> current
> >> >> way, this assumption is broken and can lead to failures as Eric said.
> >> >> If
> >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said
> if
> >> >> both
> >> >> are successfully initialized we can start Axis2 transports, which
> >> >> automatically starts Synapse.
> >> >>
> >> >> Thanks,
> >> >> Supun.
> >> >>
> >> >>
> >> >>>
> >> >>> It is a well known
> >> >>> semantic that system should be in consistent state before use it.
> You
> >> >>> can refer [1] and it says why I did.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>>
> >> >>> The way message get in to synapse and mediation engine (main
> behavior)
> >> >>> are two different aspects and definitely should have two different
> >> >>> decision designs as it is wrong if main behavior depend on other
> >> >>> behavior. The starting, shutdown --- simply state (consistent)
> >> >>> management of mediation should not depend any thing. Axis2 Hander
> is
> >> >>> make way to get message into in to synapse and for good design,
> >> >>> mediation engine should separate from this design decision. Managing
> >> >>> mediation engine should be independent from axis2 or any other.
> >> >>>
> >> >>> If it is needed to avoid effect of started listeners if the synapse
> >> >>> mediation engine started up is failed, then only applicable
> >> >>> transaction semantic is compensation transaction. In order to
> enforce
> >> >>> that, it is needed to properly shutdown listeners, etc --- some how
> >> >>> need to move into a consistent state before system startup.
> >> >>>
> >> >>> [1]
> http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
> >> >>>
> >> >>> Thanks
> >> >>> Indika
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> >>> For additional commands, e-mail: dev-help@synapse.apache.org
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Software Engineer, WSO2 Inc
> >> >> http://wso2.org
> >> >> supunk.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
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
Re: startup order - correct place to start transport listeners
Posted by Andreas Veithen <an...@gmail.com>.
I guess the HTTP(S) restriction is there for the case where Synapse is
used as an HTTP proxy. I don't see how we would get a similar behavior
with any other transport, so this actually looks right (but should be
better documented in the code).
Andreas
On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ru...@gmail.com> wrote:
> Yes, I fixed the handler module.... but what I am referring is the normal
> synapse behavior, not the handler module.
>
> For the message mediation case I think we shouldn't restrict the transports.
>
> Thanks,
> Ruwan
>
> On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <in...@gmail.com> wrote:
>>
>> Hi Runwan
>>
>> HTTP and HTTPS for synapse message mediation (_SynapseService)
>> setting was there in the previous code (Proxy service only had the per
>> service transports ) . I actually only did refractor - cut and paste
>> and change only organization. Synapse as Handler module can be
>> deployed without much effort... may three , four line ........
>>
>> Thanks
>> Indika
>>
>> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ru...@gmail.com>
>> wrote:
>> > I went through the new synapse startup logic and it seems OK but this
>> > makes
>> > the following concrete changes to the synapse architecture
>> >
>> > Synapse can no longer be deployed just as a pure module in axis2, it
>> > requires much more work.
>> > The message mediation is restricted to HTTP and HTTPS, which I am not
>> > sure
>> > whether we want to keep it as it is.
>> >
>> > But still this new logic even doesn't address the original problem in
>> > the
>> > discussion. In the new logic transport listeners starts even before the
>> > mediators getting loaded into synapse.
>> >
>> > I think we need to improve this, and to me Eric's point is completely a
>> > valid point. I will further look into resolving this and will keep the
>> > list
>> > posted.
>> >
>> > Thanks,
>> > Ruwan
>> >
>> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <su...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Indika,
>> >>
>> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <in...@gmail.com>
>> >> wrote:
>> >>>
>> >>> If the synapse is run top on axis2 or any other, it should be properly
>> >>> initialized and started before initialize synapse.
>> >>
>> >>
>> >> We are talking about two things here. Initialization and startup. I
>> >> agree
>> >> synapse should inilialize after axis2. Also Synapse should start after
>> >> Axis2. But at the moment it seems that Synapse is starting even before
>> >> it
>> >> initializes. The way Synapse is written it is perfectly normal to
>> >> assume
>> >> that it is started when Axis2 is started. But if we do it in the
>> >> current
>> >> way, this assumption is broken and can lead to failures as Eric said.
>> >> If
>> >> Axis2 is initialize properly we can initialize Synapse. As Eric said if
>> >> both
>> >> are successfully initialized we can start Axis2 transports, which
>> >> automatically starts Synapse.
>> >>
>> >> Thanks,
>> >> Supun.
>> >>
>> >>
>> >>>
>> >>> It is a well known
>> >>> semantic that system should be in consistent state before use it. You
>> >>> can refer [1] and it says why I did.
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> The way message get in to synapse and mediation engine (main behavior)
>> >>> are two different aspects and definitely should have two different
>> >>> decision designs as it is wrong if main behavior depend on other
>> >>> behavior. The starting, shutdown --- simply state (consistent)
>> >>> management of mediation should not depend any thing. Axis2 Hander is
>> >>> make way to get message into in to synapse and for good design,
>> >>> mediation engine should separate from this design decision. Managing
>> >>> mediation engine should be independent from axis2 or any other.
>> >>>
>> >>> If it is needed to avoid effect of started listeners if the synapse
>> >>> mediation engine started up is failed, then only applicable
>> >>> transaction semantic is compensation transaction. In order to enforce
>> >>> that, it is needed to properly shutdown listeners, etc --- some how
>> >>> need to move into a consistent state before system startup.
>> >>>
>> >>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
>> >>>
>> >>> Thanks
>> >>> Indika
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Software Engineer, WSO2 Inc
>> >> http://wso2.org
>> >> supunk.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
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Yes, I fixed the handler module.... but what I am referring is the normal
synapse behavior, not the handler module.
For the message mediation case I think we shouldn't restrict the transports.
Thanks,
Ruwan
On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <in...@gmail.com> wrote:
> Hi Runwan
>
> HTTP and HTTPS for synapse message mediation (_SynapseService)
> setting was there in the previous code (Proxy service only had the per
> service transports ) . I actually only did refractor - cut and paste
> and change only organization. Synapse as Handler module can be
> deployed without much effort... may three , four line ........
>
> Thanks
> Indika
>
> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ru...@gmail.com>
> wrote:
> > I went through the new synapse startup logic and it seems OK but this
> makes
> > the following concrete changes to the synapse architecture
> >
> > Synapse can no longer be deployed just as a pure module in axis2, it
> > requires much more work.
> > The message mediation is restricted to HTTP and HTTPS, which I am not
> sure
> > whether we want to keep it as it is.
> >
> > But still this new logic even doesn't address the original problem in the
> > discussion. In the new logic transport listeners starts even before the
> > mediators getting loaded into synapse.
> >
> > I think we need to improve this, and to me Eric's point is completely a
> > valid point. I will further look into resolving this and will keep the
> list
> > posted.
> >
> > Thanks,
> > Ruwan
> >
> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <su...@gmail.com>
> > wrote:
> >>
> >> Hi Indika,
> >>
> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <in...@gmail.com>
> >> wrote:
> >>>
> >>> If the synapse is run top on axis2 or any other, it should be properly
> >>> initialized and started before initialize synapse.
> >>
> >>
> >> We are talking about two things here. Initialization and startup. I
> agree
> >> synapse should inilialize after axis2. Also Synapse should start after
> >> Axis2. But at the moment it seems that Synapse is starting even before
> it
> >> initializes. The way Synapse is written it is perfectly normal to assume
> >> that it is started when Axis2 is started. But if we do it in the current
> >> way, this assumption is broken and can lead to failures as Eric said. If
> >> Axis2 is initialize properly we can initialize Synapse. As Eric said if
> both
> >> are successfully initialized we can start Axis2 transports, which
> >> automatically starts Synapse.
> >>
> >> Thanks,
> >> Supun.
> >>
> >>
> >>>
> >>> It is a well known
> >>> semantic that system should be in consistent state before use it. You
> >>> can refer [1] and it says why I did.
> >>
> >>
> >>
> >>
> >>>
> >>> The way message get in to synapse and mediation engine (main behavior)
> >>> are two different aspects and definitely should have two different
> >>> decision designs as it is wrong if main behavior depend on other
> >>> behavior. The starting, shutdown --- simply state (consistent)
> >>> management of mediation should not depend any thing. Axis2 Hander is
> >>> make way to get message into in to synapse and for good design,
> >>> mediation engine should separate from this design decision. Managing
> >>> mediation engine should be independent from axis2 or any other.
> >>>
> >>> If it is needed to avoid effect of started listeners if the synapse
> >>> mediation engine started up is failed, then only applicable
> >>> transaction semantic is compensation transaction. In order to enforce
> >>> that, it is needed to properly shutdown listeners, etc --- some how
> >>> need to move into a consistent state before system startup.
> >>>
> >>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
> >>>
> >>> Thanks
> >>> Indika
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >>> For additional commands, e-mail: dev-help@synapse.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Software Engineer, WSO2 Inc
> >> http://wso2.org
> >> supunk.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
> >
>
> ---------------------------------------------------------------------
> 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
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
Hi Runwan
HTTP and HTTPS for synapse message mediation (_SynapseService)
setting was there in the previous code (Proxy service only had the per
service transports ) . I actually only did refractor - cut and paste
and change only organization. Synapse as Handler module can be
deployed without much effort... may three , four line ........
Thanks
Indika
On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ru...@gmail.com> wrote:
> I went through the new synapse startup logic and it seems OK but this makes
> the following concrete changes to the synapse architecture
>
> Synapse can no longer be deployed just as a pure module in axis2, it
> requires much more work.
> The message mediation is restricted to HTTP and HTTPS, which I am not sure
> whether we want to keep it as it is.
>
> But still this new logic even doesn't address the original problem in the
> discussion. In the new logic transport listeners starts even before the
> mediators getting loaded into synapse.
>
> I think we need to improve this, and to me Eric's point is completely a
> valid point. I will further look into resolving this and will keep the list
> posted.
>
> Thanks,
> Ruwan
>
> On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <su...@gmail.com>
> wrote:
>>
>> Hi Indika,
>>
>> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <in...@gmail.com>
>> wrote:
>>>
>>> If the synapse is run top on axis2 or any other, it should be properly
>>> initialized and started before initialize synapse.
>>
>>
>> We are talking about two things here. Initialization and startup. I agree
>> synapse should inilialize after axis2. Also Synapse should start after
>> Axis2. But at the moment it seems that Synapse is starting even before it
>> initializes. The way Synapse is written it is perfectly normal to assume
>> that it is started when Axis2 is started. But if we do it in the current
>> way, this assumption is broken and can lead to failures as Eric said. If
>> Axis2 is initialize properly we can initialize Synapse. As Eric said if both
>> are successfully initialized we can start Axis2 transports, which
>> automatically starts Synapse.
>>
>> Thanks,
>> Supun.
>>
>>
>>>
>>> It is a well known
>>> semantic that system should be in consistent state before use it. You
>>> can refer [1] and it says why I did.
>>
>>
>>
>>
>>>
>>> The way message get in to synapse and mediation engine (main behavior)
>>> are two different aspects and definitely should have two different
>>> decision designs as it is wrong if main behavior depend on other
>>> behavior. The starting, shutdown --- simply state (consistent)
>>> management of mediation should not depend any thing. Axis2 Hander is
>>> make way to get message into in to synapse and for good design,
>>> mediation engine should separate from this design decision. Managing
>>> mediation engine should be independent from axis2 or any other.
>>>
>>> If it is needed to avoid effect of started listeners if the synapse
>>> mediation engine started up is failed, then only applicable
>>> transaction semantic is compensation transaction. In order to enforce
>>> that, it is needed to properly shutdown listeners, etc --- some how
>>> need to move into a consistent state before system startup.
>>>
>>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
>>>
>>> Thanks
>>> Indika
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>
>>
>>
>> --
>> Software Engineer, WSO2 Inc
>> http://wso2.org
>> supunk.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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Sorry for the late reply, I’ve been very busy this week. Please see my comments inline!
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.
Thanks for creating this diagram which illustrates all the states and their particular intend. Maybe this can be included in some developer documentation?
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.
Yes, the state diagram already explained this. So calling just destroy() in the shutdown hook would have the same effect as destroy() checks the current state first and then calls the appropriate methods to do the proper transition(s). In case the server is started, it first calls stop() and then calls doDestroy(). Maybe this was a bit confusing me.
On the other hand I asked myself, why SynapseStartupServlet calls ServerManager.stop() and not ServerManager.destroy() in its destroy() method. If I understand it correctly this Servlet is only used for the deployment option where Synapse runs inside a web container as a web application (WAR). For this case Synapse is initialized and destroyed via this servlet. But shouldn’t the server not only but stopped but rather completely destroyed? Who else should take care of calling ServerManager.destroy()?
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.
Well not the exact opposite order as discussed later… ;-)
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
+1
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.
+1
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.
Yes, I have noticed the Axis2 changes and updated it locally at the time the changes were not available. Thanks for keeping us updated about your changes. This way it is much easier to follow changes.
Thanks,
Eric
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <ru...@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 <ru...@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 <in...@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 <ru...@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 <in...@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 <ru...@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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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 <ru...@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 <ru...@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 <in...@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 <ru...@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 <in...@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 <ru...@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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
committed the first cut and open for review :-)
Thanks,
Ruwan
On Tue, Apr 7, 2009 at 7:05 PM, Ruwan Linton <ru...@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 <ru...@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 <in...@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 <ru...@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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <ru...@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 <in...@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 <ru...@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 <in...@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 <ru...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <in...@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 <ru...@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 <in...@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 <ru...@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
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
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 <ru...@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 <in...@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 <ru...@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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <in...@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 <ru...@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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
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 <ru...@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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <in...@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
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Eric,
On Sat, Apr 4, 2009 at 1:51 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> I put my comments inline as well.
>
>
>
> Please see my comments inline;
>
> What I meant in my original proposal is exactly this, but without
> preStart I think preStart is equivalent to the init, but we need postStart
> or some other meaning full method to do post startup tasks.
>
> Yeah, at the moment I sent my mail out I also came across the same thought.
> Did you notice my follow-up mail on this? I think we could put all calls in
> a start() method which delegates to the specific sub routines in the
> appropriate order. Actually also the tasks are part of the start process.
> It’s only the fact they are started after the listeners as they require them
> to be started in advance.
>
How can we manage the case where the task sends a request out just after its
initialization and before starting the listeners without having a post
listener start phase to start the tasks, for example MessageInjector
actually does this.
>
>
> This may not be just the tasks but also some mediators which requires to
> fetch some data from outside going through the transport senders at the
> startup??
>
> Can you give me an example here? It can’t be something which is done on
> mediate() as this can only happen once a message arrives, and thus
> transports are started. So you are talking about something which currently
> happens inside the init method, which requires the transports to be
> available. Hmmm, interesting… I have no use case in mind. Maybe other can
> help on this. Actually if this would be the case I would find it consistent
> to not only implement ManagedLifecylce but rather Startup and split the
> implementation in a init-Phase were one can only do initialisation stuff
> which does not require transports. And a start-Phase where one can do any
> kind of one-time operation on startup also requiring the transports.
>
> Of course this would break existing mediators currently doing such stuff.
> This is why I’m asking about examples and use cases.
>
True, I agree with all your concerns, but my point is that if we take just
the tasks out of the normal ManagedLifecycles and call them after starting
listeners, we are going with an assumption that task initialization is the
one only requires transport listeners.... This is a bit confusing because we
are using the same interface to mean two types of implementations and we
manage them depending on our hard coded assumptions.
I don't have a concrete example of such a case, but I think a start method
apart from the init method is required. I am not in favor of adding this to
the startup interface, because it is not intended to mark a life cycle
rather it is a concrete component of the synapse.... Startup interface can
be treated as same as the Mediator interface and the Task is the interface
that we provide for the external users to write one type of startups, which
is a quartz scheduled piece of work executed as Tasks. This is analogous to
the Command mediator, Command Mediator is an implementation of the Mediator
interface, where it provides the Command interface for the external users to
write there own commands.
One option would be to come up with a new interface to cope this new start
method requirement which is extended from the ManagedLifecycle interface,
but it introduces a new interface yet again keeps the back words
compatibility for the already existing mediators. We should properly
document this so that if a particular mediator wants to get this starting
behavior it can also use the new derived interface over the
ManagedLifecycle.
>
>
> So if we add a new method to the ManagedLifecycle called start you could,
> support these post startup work in a general manner rather than treating
> tasks starting as a special case.
> True, implementation of mediators would need to be changed either the one
> or the other way. I just don’t see so many use cases for the start()-method,
> but I may be wrong. Also any mediator could decide to implement
> ManagedLifecycle or some more specific interface extended by the startup
> behaviour. Otherwise you would often leave this method without
> implementation.
>
+1, it is not going to be a Startup derived interface rather a new interface
derived from the ManagedLifecycle, because Startups are more specific to
task like components, with some more methods in it.
> Ok, looking inside the Startup interface it only sounds to be generic but
> infact it seems to be just a synonym for task, or?
>
Not really a synonym, I think I explained the relation between Startup and
Task in the above section.
> So I could also life with a ManagedLifecycle interface extended by a new
> start() method keeping this method always empty for my use cases. Of course
> this has also an advantage for the user. Only one interface to care about.
>
Agree, we could provide a abstract class with the startup method implemented
to get rid of the blank implementation in each and every mediator. I prefer
to change the ManagedLifecycle interface itself, but OK with going for a new
interface as well.
>
>
> What are other’s opinions? How shall we go on? Ruwan, would you do those
> changes on your own.
>
I would like to do this on my own, after gathering the feedback and I think
even now we are clear about certain things... so I will get started.
> If you would need some support, I could do this today. Today I have some
> hours I could spend. Tomorrow and next week doesn’t look too good on my
> side.
>
Eric, I think it is better to do this by one person, after the
implementation is completed I will let you all know for a review and for any
changes/improvements. I think that is the practical model for this sort of a
change. :-)
> Otherwise I will proceed with my work on the JMX stuff to remove some open
> issues as of the comments in the JIRA (the integration shouldn’t be done
> before the startup/shutdown has been changed though, I will then sync and
> update my patch accordingly) and a small patch regarding log output in the
> http transports. Looks like either way I will find enough useful stuff to
> help with today.
>
+1
Thanks,
Ruwan
>
>
> 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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
I put my comments inline as well.
Please see my comments inline;
What I meant in my original proposal is exactly this, but without preStart I think preStart is equivalent to the init, but we need postStart or some other meaning full method to do post startup tasks.
Yeah, at the moment I sent my mail out I also came across the same thought. Did you notice my follow-up mail on this? I think we could put all calls in a start() method which delegates to the specific sub routines in the appropriate order. Actually also the tasks are part of the start process. It’s only the fact they are started after the listeners as they require them to be started in advance.
This may not be just the tasks but also some mediators which requires to fetch some data from outside going through the transport senders at the startup??
Can you give me an example here? It can’t be something which is done on mediate() as this can only happen once a message arrives, and thus transports are started. So you are talking about something which currently happens inside the init method, which requires the transports to be available. Hmmm, interesting… I have no use case in mind. Maybe other can help on this. Actually if this would be the case I would find it consistent to not only implement ManagedLifecylce but rather Startup and split the implementation in a init-Phase were one can only do initialisation stuff which does not require transports. And a start-Phase where one can do any kind of one-time operation on startup also requiring the transports.
Of course this would break existing mediators currently doing such stuff. This is why I’m asking about examples and use cases.
So if we add a new method to the ManagedLifecycle called start you could, support these post startup work in a general manner rather than treating tasks starting as a special case.
True, implementation of mediators would need to be changed either the one or the other way. I just don’t see so many use cases for the start()-method, but I may be wrong. Also any mediator could decide to implement ManagedLifecycle or some more specific interface extended by the startup behaviour. Otherwise you would often leave this method without implementation.
Ok, looking inside the Startup interface it only sounds to be generic but infact it seems to be just a synonym for task, or?
So I could also life with a ManagedLifecycle interface extended by a new start() method keeping this method always empty for my use cases. Of course this has also an advantage for the user. Only one interface to care about.
What are other’s opinions? How shall we go on? Ruwan, would you do those changes on your own. If you would need some support, I could do this today. Today I have some hours I could spend. Tomorrow and next week doesn’t look too good on my side.
Otherwise I will proceed with my work on the JMX stuff to remove some open issues as of the comments in the JIRA (the integration shouldn’t be done before the startup/shutdown has been changed though, I will then sync and update my patch accordingly) and a small patch regarding log output in the http transports. Looks like either way I will find enough useful stuff to help with today.
Regards,
Eric
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Eric,
Please see my comments inline;
>
> Does this correctly reflect your idea Ruwan?
>
>
>
> What about this slight modification?
>
>
>
> 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.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(configurationContext.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
>
What I meant in my original proposal is exactly this, but without preStart I
think preStart is equivalent to the init, but we need postStart or some
other meaning full method to do post startup tasks. This may not be just the
tasks but also some mediators which requires to fetch some data from outside
going through the transport senders at the startup??
So if we add a new method to the ManagedLifecycle called start you could,
support these post startup work in a general manner rather than treating
tasks starting as a special case.
>
>
> 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.
>
Exactly this is what I meant.
>
>
> 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 <Er...@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
>
--
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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hmm, please forget about my preStart(), postStart() naming suggestion! It is somehow misleading. Maybe better putting everything in a single start() method:
1.4 ServerManager.start()
1.4.1 ServerManager.assertInitialized()
1.4.2 ServerManager.doInit()
1.4.3 ServerManager.doStart()
1.4.3.1 Axis2SynapseController.start() <-- 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.1.2.3 Axis2SynapseController.startListeners() <-- starts Listener Manager, which in turn start all registered transports
1.4.3.1.2.4 Axis2SynapseController.startStartups() <-- start all startups (currently only tasks)
But the basic order sounds to be correct.
________________________________
From: Hubert, Eric [mailto:Eric.Hubert@foxmobile.com]
Sent: Friday, April 03, 2009 10:56 PM
To: dev@synapse.apache.org
Subject: RE: startup order - correct place to start transport listeners
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.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.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(configurationContext.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.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.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(configurationContext.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.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.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(configurationContext.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 <Er...@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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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 <Er...@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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Er...@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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
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 <in...@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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> I wrote the code to get the engine to wait a maximum number of seconds -
> for these in-process messages to complete, the callbacks to get replies
> etc. However, once the graceful timeout specified by a user expires, we
> shutdown the engine. This code is already within the WSO2 ESB 1.7.x and
> is valid for Synapse to be brought in.
I'd be + 1 to integrate this as a core functionality once Ruwan has finished his work on the startup and shutdown logic.
I also share Indika's evaluation that this is a core functionality which should be closely integrated with the other start- and shutup logic.
Regards,
Eric
Re: startup order - correct place to start transport listeners
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Indika
We already have the capability to shutdown gracefully, or on demand. In
a graceful shutdown request, we first turn off accepting new messages.
But continue processing already accepted and processing messages. So the
messages already in the engine can work normally, send out requests,
accept responses etc. The transport listeners (e.g. HTTP/S) are also
up.. and once responses are ready on open sockets, they would still
continue to send back responses to the clients that are still connected.
Its only new requests that are stopped.
I wrote the code to get the engine to wait a maximum number of seconds -
for these in-process messages to complete, the callbacks to get replies
etc. However, once the graceful timeout specified by a user expires, we
shutdown the engine. This code is already within the WSO2 ESB 1.7.x and
is valid for Synapse to be brought in
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
On Thu, Apr 2, 2009 at 7:07 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> Makes perfectly sense Ruwan, and I did think about it as a seconds step
> as well! Just wanted to mention it, as from a user’s perspective the same
> problems which may arise at startup can also arise at shutdown. And once
> something is fresh in memory, those changes are easier to perform. Thanks
> for taking the time for improving this.
>
> Once you are done, I’m of course willing to do a review.
>
+1
Ruwan
>
>
> Thanks,
>
> Eric
>
>
>
>
> ------------------------------
>
> *From:* Ruwan Linton [mailto:ruwan.linton@gmail.com]
> *Sent:* Thursday, April 02, 2009 2:51 PM
>
> *To:* dev@synapse.apache.org
> *Subject:* Re: startup order - correct place to start transport listeners
>
>
>
> Eric,
>
> I agree with the comments and I will be looking into the start order first
> to address your issue, and then I will change the stop process in a way that
> it does exactly the opposite. If we change it now and had to change it after
> fixing the start order that is going to be a double work for the stop
> process.
>
> Thanks,
> Ruwan
>
> On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric <Er...@foxmobile.com>
> wrote:
>
> Hi Ruwan,
>
>
>
> thanks for taking the time to review the startup/shutdown logic
> implemented. In terms of structure and readability I also widely liked the
> changes. I have only those real world usage’s concerns. So if you are
> already at it could you please also look at the shutdown process!
>
> In most situations the correct shutdown order is exactly the opposite of
> the startup order. And honestly, this is what I also would expect here.
>
>
>
> Specifically please have a look at ServerManager.doStart() versus
> ServerManager.doStop()!
>
>
>
> Start:
>
> Create Synapse Configuration
>
> Create Synapse Environment
>
>
>
> Stop:
>
> Destroy Synapse Configuration
>
> Destroy Synapse Environment
>
> Destroy ß only here listeners will be stopped (in the mean time the
> instance keeps accepting requests which can’t be processed as everything
> else has already been stopped/deactivated)
>
>
>
> To me this looks wrong.
>
>
>
> Regards,
>
> Eric
>
>
> ------------------------------
>
> *From:* Ruwan Linton [mailto:ruwan.linton@gmail.com]
> *Sent:* Thursday, April 02, 2009 3:59 AM
>
>
> *To:* dev@synapse.apache.org
> *Subject:* Re: startup order - correct place to start transport listeners
>
>
>
> I went through the new synapse startup logic and it seems OK but this makes
> the following concrete changes to the synapse architecture
>
> - Synapse can no longer be deployed just as a pure module in axis2, it
> requires much more work.
> - The message mediation is restricted to HTTP and HTTPS, which I am not
> sure whether we want to keep it as it is.
>
> But still this new logic even doesn't address the original problem in the
> discussion. In the new logic transport listeners starts even before the
> mediators getting loaded into synapse.
>
> I think we need to improve this, and to me Eric's point is completely a
> valid point. I will further look into resolving this and will keep the list
> posted.
>
>
>
>
> --
> 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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Makes perfectly sense Ruwan, and I did think about it as a seconds step as well! Just wanted to mention it, as from a user’s perspective the same problems which may arise at startup can also arise at shutdown. And once something is fresh in memory, those changes are easier to perform. Thanks for taking the time for improving this.
Once you are done, I’m of course willing to do a review.
Thanks,
Eric
________________________________
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Thursday, April 02, 2009 2:51 PM
To: dev@synapse.apache.org
Subject: Re: startup order - correct place to start transport listeners
Eric,
I agree with the comments and I will be looking into the start order first to address your issue, and then I will change the stop process in a way that it does exactly the opposite. If we change it now and had to change it after fixing the start order that is going to be a double work for the stop process.
Thanks,
Ruwan
On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric <Er...@foxmobile.com> wrote:
Hi Ruwan,
thanks for taking the time to review the startup/shutdown logic implemented. In terms of structure and readability I also widely liked the changes. I have only those real world usage’s concerns. So if you are already at it could you please also look at the shutdown process!
In most situations the correct shutdown order is exactly the opposite of the startup order. And honestly, this is what I also would expect here.
Specifically please have a look at ServerManager.doStart() versus ServerManager.doStop()!
Start:
Create Synapse Configuration
Create Synapse Environment
Stop:
Destroy Synapse Configuration
Destroy Synapse Environment
Destroy <-- only here listeners will be stopped (in the mean time the instance keeps accepting requests which can’t be processed as everything else has already been stopped/deactivated)
To me this looks wrong.
Regards,
Eric
________________________________
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Thursday, April 02, 2009 3:59 AM
To: dev@synapse.apache.org
Subject: Re: startup order - correct place to start transport listeners
I went through the new synapse startup logic and it seems OK but this makes the following concrete changes to the synapse architecture
* Synapse can no longer be deployed just as a pure module in axis2, it requires much more work.
* The message mediation is restricted to HTTP and HTTPS, which I am not sure whether we want to keep it as it is.
But still this new logic even doesn't address the original problem in the discussion. In the new logic transport listeners starts even before the mediators getting loaded into synapse.
I think we need to improve this, and to me Eric's point is completely a valid point. I will further look into resolving this and will keep the list posted.
--
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
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Eric,
I agree with the comments and I will be looking into the start order first
to address your issue, and then I will change the stop process in a way that
it does exactly the opposite. If we change it now and had to change it after
fixing the start order that is going to be a double work for the stop
process.
Thanks,
Ruwan
On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> Hi Ruwan,
>
>
>
> thanks for taking the time to review the startup/shutdown logic
> implemented. In terms of structure and readability I also widely liked the
> changes. I have only those real world usage’s concerns. So if you are
> already at it could you please also look at the shutdown process!
>
> In most situations the correct shutdown order is exactly the opposite of
> the startup order. And honestly, this is what I also would expect here.
>
>
>
> Specifically please have a look at ServerManager.doStart() versus
> ServerManager.doStop()!
>
>
>
> Start:
>
> Create Synapse Configuration
>
> Create Synapse Environment
>
>
>
> Stop:
>
> Destroy Synapse Configuration
>
> Destroy Synapse Environment
>
> Destroy ß only here listeners will be stopped (in the mean time the
> instance keeps accepting requests which can’t be processed as everything
> else has already been stopped/deactivated)
>
>
>
> To me this looks wrong.
>
>
>
> Regards,
>
> Eric
>
>
> ------------------------------
>
> *From:* Ruwan Linton [mailto:ruwan.linton@gmail.com]
> *Sent:* Thursday, April 02, 2009 3:59 AM
> *To:* dev@synapse.apache.org
> *Subject:* Re: startup order - correct place to start transport listeners
>
>
>
> I went through the new synapse startup logic and it seems OK but this makes
> the following concrete changes to the synapse architecture
>
> - Synapse can no longer be deployed just as a pure module in axis2, it
> requires much more work.
> - The message mediation is restricted to HTTP and HTTPS, which I am not
> sure whether we want to keep it as it is.
>
> But still this new logic even doesn't address the original problem in the
> discussion. In the new logic transport listeners starts even before the
> mediators getting loaded into synapse.
>
> I think we need to improve this, and to me Eric's point is completely a
> valid point. I will further look into resolving this and will keep the list
> posted.
>
--
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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi Ruwan,
thanks for taking the time to review the startup/shutdown logic implemented. In terms of structure and readability I also widely liked the changes. I have only those real world usage’s concerns. So if you are already at it could you please also look at the shutdown process!
In most situations the correct shutdown order is exactly the opposite of the startup order. And honestly, this is what I also would expect here.
Specifically please have a look at ServerManager.doStart() versus ServerManager.doStop()!
Start:
Create Synapse Configuration
Create Synapse Environment
Stop:
Destroy Synapse Configuration
Destroy Synapse Environment
Destroy <-- only here listeners will be stopped (in the mean time the instance keeps accepting requests which can’t be processed as everything else has already been stopped/deactivated)
To me this looks wrong.
Regards,
Eric
________________________________
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: Thursday, April 02, 2009 3:59 AM
To: dev@synapse.apache.org
Subject: Re: startup order - correct place to start transport listeners
I went through the new synapse startup logic and it seems OK but this makes the following concrete changes to the synapse architecture
* Synapse can no longer be deployed just as a pure module in axis2, it requires much more work.
* The message mediation is restricted to HTTP and HTTPS, which I am not sure whether we want to keep it as it is.
But still this new logic even doesn't address the original problem in the discussion. In the new logic transport listeners starts even before the mediators getting loaded into synapse.
I think we need to improve this, and to me Eric's point is completely a valid point. I will further look into resolving this and will keep the list posted.
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
I went through the new synapse startup logic and it seems OK but this makes
the following concrete changes to the synapse architecture
- Synapse can no longer be deployed just as a pure module in axis2, it
requires much more work.
- The message mediation is restricted to HTTP and HTTPS, which I am not
sure whether we want to keep it as it is.
But still this new logic even doesn't address the original problem in the
discussion. In the new logic transport listeners starts even before the
mediators getting loaded into synapse.
I think we need to improve this, and to me Eric's point is completely a
valid point. I will further look into resolving this and will keep the list
posted.
Thanks,
Ruwan
On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva <su...@gmail.com>wrote:
> Hi Indika,
>
> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <in...@gmail.com>wrote:
>
>> If the synapse is run top on axis2 or any other, it should be properly
>> initialized and started before initialize synapse.
>
>
> We are talking about two things here. Initialization and startup. I agree
> synapse should inilialize after axis2. Also Synapse should start after
> Axis2. But at the moment it seems that Synapse is starting even before it
> initializes. The way Synapse is written it is perfectly normal to assume
> that it is started when Axis2 is started. But if we do it in the current
> way, this assumption is broken and can lead to failures as Eric said. If
> Axis2 is initialize properly we can initialize Synapse. As Eric said if both
> are successfully initialized we can start Axis2 transports, which
> automatically starts Synapse.
>
> Thanks,
> Supun.
>
>
>
>> It is a well known
>> semantic that system should be in consistent state before use it. You
>> can refer [1] and it says why I did.
>>
>
>
>
>
>>
>> The way message get in to synapse and mediation engine (main behavior)
>> are two different aspects and definitely should have two different
>> decision designs as it is wrong if main behavior depend on other
>> behavior. The starting, shutdown --- simply state (consistent)
>> management of mediation should not depend any thing. Axis2 Hander is
>> make way to get message into in to synapse and for good design,
>> mediation engine should separate from this design decision. Managing
>> mediation engine should be independent from axis2 or any other.
>>
>> If it is needed to avoid effect of started listeners if the synapse
>> mediation engine started up is failed, then only applicable
>> transaction semantic is compensation transaction. In order to enforce
>> that, it is needed to properly shutdown listeners, etc --- some how
>> need to move into a consistent state before system startup.
>>
>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
>>
>> Thanks
>> Indika
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.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
Re: startup order - correct place to start transport listeners
Posted by Supun Kamburugamuva <su...@gmail.com>.
Hi Indika,
On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <in...@gmail.com>wrote:
> If the synapse is run top on axis2 or any other, it should be properly
> initialized and started before initialize synapse.
We are talking about two things here. Initialization and startup. I agree
synapse should inilialize after axis2. Also Synapse should start after
Axis2. But at the moment it seems that Synapse is starting even before it
initializes. The way Synapse is written it is perfectly normal to assume
that it is started when Axis2 is started. But if we do it in the current
way, this assumption is broken and can lead to failures as Eric said. If
Axis2 is initialize properly we can initialize Synapse. As Eric said if both
are successfully initialized we can start Axis2 transports, which
automatically starts Synapse.
Thanks,
Supun.
> It is a well known
> semantic that system should be in consistent state before use it. You
> can refer [1] and it says why I did.
>
>
> The way message get in to synapse and mediation engine (main behavior)
> are two different aspects and definitely should have two different
> decision designs as it is wrong if main behavior depend on other
> behavior. The starting, shutdown --- simply state (consistent)
> management of mediation should not depend any thing. Axis2 Hander is
> make way to get message into in to synapse and for good design,
> mediation engine should separate from this design decision. Managing
> mediation engine should be independent from axis2 or any other.
>
> If it is needed to avoid effect of started listeners if the synapse
> mediation engine started up is failed, then only applicable
> transaction semantic is compensation transaction. In order to enforce
> that, it is needed to properly shutdown listeners, etc --- some how
> need to move into a consistent state before system startup.
>
> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
>
> Thanks
> Indika
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: startup order - correct place to start transport listeners
Posted by indika kumara <in...@gmail.com>.
If the synapse is run top on axis2 or any other, it should be properly
initialized and started before initialize synapse. It is a well known
semantic that system should be in consistent state before use it. You
can refer [1] and it says why I did.
The way message get in to synapse and mediation engine (main behavior)
are two different aspects and definitely should have two different
decision designs as it is wrong if main behavior depend on other
behavior. The starting, shutdown --- simply state (consistent)
management of mediation should not depend any thing. Axis2 Hander is
make way to get message into in to synapse and for good design,
mediation engine should separate from this design decision. Managing
mediation engine should be independent from axis2 or any other.
If it is needed to avoid effect of started listeners if the synapse
mediation engine started up is failed, then only applicable
transaction semantic is compensation transaction. In order to enforce
that, it is needed to properly shutdown listeners, etc --- some how
need to move into a consistent state before system startup.
[1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html
Thanks
Indika
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: startup order - correct place to start transport listeners
Posted by Ruwan Linton <ru...@gmail.com>.
Eric,
On Sun, Mar 29, 2009 at 3:05 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> Hi all,
>
> hmm, I quickly tried to change the order and it seems to work without
> problems.
>
> > This is a side effect of the historical and now burned-in dependency on
> > Axis2.. In Synapse, the startup script actually starts Axis2, and then
> > again gets triggered on the startup of Axis2, for the actual Synapse
> > initialization
>
> Are you sure this is still the case? I noticed Axis2 is calling init() of
> class SynapseInitializationModule.
> But recently the implementation of this method has been completely removed
> (change by Indika on 02.03.2009). Now Synapse seems to initialize more
> independently of Axis2. I could be wrong, as I still don't know the code
> very well.
I just had a look at the changes and realized that this change completely
turned the synapse startup and the architecture upside down. Indika, this
will break the Synapse handler module as well. In other words now synapse is
not initializing as a module of axis2 which I think is wrong and might cause
issues. What was the requirement for this sort of a change?????
Ruwan.
>
>
> > I do not think this would be possible.. but please feel free to explore
> > any possibilities
> I just tried it out and it looks like working. I would post a patch for
> review, but unfortunately my working file of Axis2SynapseController.java
> also contains my changes for
> https://issues.apache.org/jira/browse/SYNAPSE-526
>
> So I would first need to get a clean copy from the repo and merge only
> those changes to provide a useful diff to illustrate the changes.
>
> 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
RE: startup order - correct place to start transport listeners
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi all,
hmm, I quickly tried to change the order and it seems to work without problems.
> This is a side effect of the historical and now burned-in dependency on
> Axis2.. In Synapse, the startup script actually starts Axis2, and then
> again gets triggered on the startup of Axis2, for the actual Synapse
> initialization
Are you sure this is still the case? I noticed Axis2 is calling init() of class SynapseInitializationModule.
But recently the implementation of this method has been completely removed (change by Indika on 02.03.2009). Now Synapse seems to initialize more independently of Axis2. I could be wrong, as I still don't know the code very well.
> I do not think this would be possible.. but please feel free to explore
> any possibilities
I just tried it out and it looks like working. I would post a patch for review, but unfortunately my working file of Axis2SynapseController.java also contains my changes for https://issues.apache.org/jira/browse/SYNAPSE-526
So I would first need to get a clean copy from the repo and merge only those changes to provide a useful diff to illustrate the changes.
Regards,
Eric
Re: startup order - correct place to start transport listeners
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Eric
> If I'm not wrong it looks like the transports are started somewhere in the middle of the Synapse startup. Is this observation correct? Is this on purpose? Too me this looks like a serious error.
>
This is a side effect of the historical and now burned-in dependency on
Axis2.. In Synapse, the startup script actually starts Axis2, and then
again gets triggered on the startup of Axis2, for the actual Synapse
initialization
> The listeners should be started only once the whole configuration process has been successfully finished. Otherwise traffic would be accepted even though the initialization of the configuration (proxies, sequences, endpoints and so on) may fail.
>
> Here is what I have read from the code (standalone deployment):
> 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.2 create and Init Listener Manager
> 1.3.2.1.3 start transports <--- this looks terribly wrong
> 1.3.2.2 Axis2SynapseController.initDefaults()
> 1.3.2.2.1 Axis2SynapseController.addDefaultBuildersAndFormatters(configurationContext.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()
> --> up to this point a lot of errors can occur resulting in "Synapse startup failed"
>
> Why don't we start listeners only if we reach this point without an error?
>
Since we have no control in the startup of Axis2, as from the pov of
Axis2, Synapse is just a module
> I would propose to start the listeners immediately before the log output:
> ServerManager - Ready for processing
>
> Is there anything which will prevent this to work? If not I would be willing to work on a patch.
>
I do not think this would be possible.. but please feel free to explore
any possibilities
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org