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 Sat, 04 Apr 2009 04:27:06 GMT
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
<andreas.veithen@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 <ruwan.linton@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 <ruwan.linton@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 <indika.kuma@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
> >> >> > <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
> >
>
> ---------------------------------------------------------------------
> 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