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 Tue, 07 Apr 2009 13:35:15 GMT
I've completed most of the implementation of the first cut... and waiting on
this fix [1] in axis2 to make it 100% accurate. :-)

Thanks,
Ruwan

[1] - https://issues.apache.org/jira/browse/AXIS2-4304

On Mon, Apr 6, 2009 at 10:18 PM, Ruwan Linton <ruwan.linton@gmail.com>wrote:

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



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

Mime
View raw message