synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: startup order - correct place to start transport listeners
Date Mon, 06 Apr 2009 16:48:47 GMT
I am in the process of implementing this....

I found a few issues and had to take a few decisions.

Issues :- The existing approach doesn't prevent messages to be flowing into
synapse before deploying proxies and so on, because the message interception
handlers are attached through the module while the synapse initialization is
handled out of the module initialization.

I found it impossible to implement the listener manager initialization and
startup to be different, even though I was planing to do so.

Decisions :- Add the start and stop methods to the ManagedLifecycle
No need of an post start method to the controller, but inside the
controller.start, call the ManagedLifecycle.start()

Will be able to commit the first cut soon.

Thanks,
Ruwan

On Mon, Apr 6, 2009 at 9:39 AM, indika kumara <indika.kuma@gmail.com> wrote:

> Ruwan
>
> I never said that suggested approach is bad. if you have confidence
> that approach will work , then it is good . Generally , a problem have
> many solutions. I just say what I like.
> You will go on your way. If it can achieve what we need , then it is a
> good solution.
>
> Thanks
> Indika
>
> On Sun, Apr 5, 2009 at 3:07 PM, Ruwan Linton <ruwan.linton@gmail.com>
> wrote:
> > Indika,
> >
> > If we are going for such a change it has to go into axis2 and I think it
> is
> > late to get this to axis2 1.5, and I think this is much cleaner.... can
> you
> > point any issue with this approach? Any reasoning to not to add a start
> > method....
> >
> > Thanks,
> > Ruwan
> >
> > On Sun, Apr 5, 2009 at 12:24 PM, indika kumara <indika.kuma@gmail.com>
> > wrote:
> >>
> >> Runwan
> >>
> >> I personally like, if there are some fixes need to be done on
> >> transport layer, if it could be done.
> >>
> >> BTW, it is good if we can cope (by the implementation we are going to
> >> do) transparently with current and future behaviors of transports as
> >> synapse always operate top on that.
> >>
> >> Thanks
> >> Indika
> >>
> >> On Sun, Apr 5, 2009 at 11:33 AM, Ruwan Linton <ruwan.linton@gmail.com>
> >> wrote:
> >> > Indika,
> >> >
> >> > I think having a start method is much cleaner than this, because
> >> >
> >> > listener manager doesn't support adding the transport in the
> maintenance
> >> > mode...
> >> > if we try to start and then put the transport into the maintenance
> mode
> >> > even
> >> > then there is a time where the transports are exposed to the external
> >> > users
> >> > before synapse initialization
> >> > Not all the transports support maintenance mode
> >> >
> >> > So I would go with the above proposed approach, which is much cleaner.
> >> >
> >> > Thanks,
> >> > Ruwan
> >> >
> >> > On Sun, Apr 5, 2009 at 10:57 AM, indika kumara <indika.kuma@gmail.com
> >
> >> > wrote:
> >> >>
> >> >> Hi All
> >> >>
> >> >> I am not sure but could we achieve following event sequence?
> >> >>
> >> >> Initializing…………….
> >> >>
> >> >> Initialized and start transport on graceful mode
> >> >> Create synapse configuration
> >> >> Create synapse environment
> >> >> Initialized synapse configuration
> >> >> Change the mode of listeners to fully active
> >> >>
> >> >> Shouting down ……………….
> >> >>
> >> >> Signal to change the mode of transport into graceful
> >> >> destroy synapse configuration and synapse environment
> >> >> Signal to completely destroy transport
> >> >>
> >> >> Could we achieve what we need with above order sequence of events?
If
> >> >> it can, I feel we never want to change any API.
> >> >>
> >> >> Thanks
> >> >> Indika
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Ruwan Linton
> >> > Senior Software Engineer & Product Manager; WSO2 ESB;
> >> > http://wso2.org/esb
> >> > WSO2 Inc.; http://wso2.org
> >> > email: ruwan@wso2.com; cell: +94 77 341 3097
> >> > blog: http://ruwansblog.blogspot.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >>
> >
> >
> >
> > --
> > Ruwan Linton
> > Senior Software Engineer & Product Manager; WSO2 ESB;
> http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ruwan@wso2.com; cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message