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 <[email protected]>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 <[email protected]> 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 < > [email protected]> > > 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 <[email protected]> > 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 <[email protected]> > >> > 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 <[email protected] > > > >> >> 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 > >> >> > <[email protected]> > >> >> > wrote: > >> >> >> > >> >> >> Hi Indika, > >> >> >> > >> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara > >> >> >> <[email protected]> > >> >> >> 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/[email protected]/msg02688.html > >> >> >>> > >> >> >>> Thanks > >> >> >>> Indika > >> >> >>> > >> >> >>> > >> >> >>> > --------------------------------------------------------------------- > >> >> >>> To unsubscribe, e-mail: [email protected] > >> >> >>> For additional commands, e-mail: [email protected] > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> 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: [email protected]; cell: +94 77 341 3097 > >> >> > blog: http://ruwansblog.blogspot.com > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> > > >> > > >> > > >> > -- > >> > Ruwan Linton > >> > Senior Software Engineer & Product Manager; WSO2 ESB; > >> > http://wso2.org/esb > >> > WSO2 Inc.; http://wso2.org > >> > email: [email protected]; cell: +94 77 341 3097 > >> > blog: http://ruwansblog.blogspot.com > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > > > -- > > Ruwan Linton > > Senior Software Engineer & Product Manager; WSO2 ESB; > http://wso2.org/esb > > WSO2 Inc.; http://wso2.org > > email: [email protected]; cell: +94 77 341 3097 > > blog: http://ruwansblog.blogspot.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
