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 <supu...@gmail.com>wrote: > Hi Indika, > > On Tue, Mar 31, 2009 at 10:02 AM, indika kumara <indika.k...@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-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@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: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
