Hi, If some one want's to wait for the response and continue further with the response in a non blocking manner, he can still use <send receive=""/>. AFAIU, apparently the only advantage of <send continuation="true"/> *for a user* is, it will reduce the complexity of chaining sequences as with <send receive=""/> which still really makes sense and useful for users to easily implement their service chaining. +1 and thanks for the explanation.
On Wed, Aug 28, 2013 at 10:11 PM, Paul Fremantle <[email protected]> wrote: > so <send continuation=true> is basically non-blocking callout? > > Paul > > > On 28 August 2013 17:33, Kasun Indrasiri <[email protected]> wrote: > >> >> >> >> On Wed, Aug 28, 2013 at 9:06 PM, Subash Chaturanga <[email protected]>wrote: >> >>> Hi >>> >>> On Wed, Aug 28, 2013 at 10:44 AM, Kasun Indrasiri <[email protected]>wrote: >>> >>>> We had a design and code review on the blocking sender implementation >>>> on top of non-blocking transports. The new implementation works fine with >>>> almost all the scenarios (including complex scenarios such as >>>> iterate/clone/aggregate) and for all proxy services/sequence/apis. >>>> The new JIRA connector is implemented with the new blocking sender >>>> impl/HTTP Endpoint. >>>> So, I think we are good to go ahead with this. This greatly simplifying >>>> most of the service chaining scenarios where we had to use both in-out >>>> sequences. >>>> >>>> sample config : >>>> >>>> ... >>>> <send continuation="true"> >>>> <endpoint> >>>> <http method="POST" uri-template="{uri.var.jira.ur >>>> l}/rest/api/2/issue" /> >>>> </endpoint> >>>> </send> >>>> <!-- flow resumes from here --> >>>> >>> >>> For a user, what is the difference/advantage using <send >>> receive="someSequence"/> vs <send continuation="true"/> >>> >>> >> Mainly he can get the callout behavior with continuation=true, in which >> he can totally eliminate the use of receiving sequences with no performance >> penalty(unlike in callout with blocking transport). For instance, one >> sequence may contain all the service chaining logic. >> >>> ... >>>> >>>> >>>> On Tue, Aug 13, 2013 at 12:19 AM, Isuru Udana <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> Before differing this task, I implement a quick POC and manage to get >>>>> this to work for the sequence flows which does not contain list mediators >>>>> like Filter, Switch etc. >>>>> >>>>> Flow >>>>> ------ >>>>> >>>>> Proxy >>>>> InSequence >>>>> Log - IN SEQ P1 >>>>> Sequence Mediator ----> Sequence 1 >>>>> Log - IN SEQ P2 Log - SEQ1 P1 >>>>> Sequence >>>>> Mediator ----> Sequence 2 >>>>> Log - SEQ1 >>>>> P2 Log - SEQ2 P1 >>>>> Send >>>>> Send >>>>> Log - SEQ1 >>>>> P3 Log - SEQ2 P2 >>>>> >>>>> >>>>> Output on the console >>>>> ------------------------------- >>>>> >>>>> [2013-08-09 20:20:12,283] INFO - LogMediator MSG = IN SEQ P1 >>>>> [2013-08-09 20:20:12,285] INFO - LogMediator MSG = SEQ1 P1 >>>>> [2013-08-09 20:20:12,286] INFO - LogMediator MSG = SEQ2 P1 >>>>> [2013-08-09 20:20:12,303] INFO - LogMediator MSG = SEQ2 P2 >>>>> [2013-08-09 20:20:12,304] INFO - LogMediator MSG = SEQ1 P2 >>>>> [2013-08-09 20:20:12,320] INFO - LogMediator MSG = SEQ1 P3 >>>>> [2013-08-09 20:20:12,321] INFO - LogMediator MSG = IN SEQ P2 >>>>> >>>>> >>>>> Rather than implementing a new mediator, I introduced a >>>>> new parameter for the send mediator called "continuation". >>>>> >>>>> <send continuation="true"/> >>>>> >>>>> After setting the continuation to true, mediation is continued from >>>>> the next mediator placed after the send mediator with the received >>>>> response. >>>>> When flow is completed in a particular sequence, mediation will be >>>>> continued from the parent sequence. Behavior is identical to the Callout >>>>> mediator. >>>>> >>>>> Over the weekend, I put some effort to see whether I can extend this >>>>> to support sequence flows which contains other list mediators like Filter, >>>>> Switch, etc and managed to get it to work. >>>>> And managed to get this to work for Templates as well. >>>>> >>>>> Design in brief >>>>> --------------------- >>>>> >>>>> - To keep track of sequence branching, a stack (called 'Sequence >>>>> Calls Stack') is kept in the message context which is similar to the >>>>> fault >>>>> stack. >>>>> - Every time when we branch to a new sequence, a entry (called >>>>> 'SequenceCall') is pushed in to the stack. >>>>> - A SequenceCall contains the sequence name and the position of >>>>> the mediator in the sequence. >>>>> - When branching to a new sequence, top is updated with the >>>>> current mediator position. >>>>> - When message is sent out from the send mediator, top is updated >>>>> with the current mediator position and a property is added to the >>>>> message >>>>> context to indicate continuation=true. And flow will be stopped from >>>>> there. >>>>> - When response is received, while injecting the response at the >>>>> Axis2SynapseEnvironment, it checks for the continuation property from >>>>> the >>>>> message context. If it is present, it will peek the stack and using the >>>>> information contain in that peeked SequenceCall, mediation will be >>>>> continued from where it stopped earlier. >>>>> >>>>> Above is a very high level description of the design I came up with. >>>>> Actual design which I implemented to support other list mediators and >>>>> templates is bit more complex than this. >>>>> >>>>> Today I had a peer review with Kasun on this implementation. >>>>> Source of the current implementation is located at [1] and tested >>>>> artifacts are located at [2]. >>>>> >>>>> [1] >>>>> https://svn.wso2.org/repos/wso2/people/isuruu/non-blocking-callout-impl/2.1.1-wso2v8 >>>>> [2] >>>>> https://svn.wso2.org/repos/wso2/people/isuruu/non-blocking-callout-impl/test-artifacts >>>>> >>>>> >>>>> Thanks, >>>>> IsuruU >>>>> >>>>> >>>>> On Mon, Aug 12, 2013 at 10:42 PM, Sanjiva Weerawarana < >>>>> [email protected]> wrote: >>>>> >>>>>> As discussed .. this is not a real need so we'll defer. >>>>>> >>>>>> >>>>>> On Thu, Aug 8, 2013 at 3:07 PM, Kasun Indrasiri <[email protected]>wrote: >>>>>> >>>>>>> We have been discussing the $subject for sometime and I guess now >>>>>>> we have a real requirement for this with connectors. Since most >>>>>>> connectors >>>>>>> uses callout mediator for external calls, we will surely experience >>>>>>> perf-issues when the connectors are used in real world scenarios. >>>>>>> >>>>>>> So, we should make callout work with non-blocking transports. This >>>>>>> is not a trivial thing to implement as we have to implement a blocking >>>>>>> scenario on top of a non-blocking transport, but it should be possible >>>>>>> to >>>>>>> do something along the lines of receiving seq impl we have at the >>>>>>> moment. >>>>>>> >>>>>>> Isuru is currently looking for a possible design to implement this. >>>>>>> >>>>>>> -- >>>>>>> Kasun Indrasiri >>>>>>> Software Architect >>>>>>> WSO2, Inc.; http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> cell: +94 71 536 4128 >>>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sanjiva Weerawarana, Ph.D. >>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 >>>>>> 6880 | +1 650 265 8311 >>>>>> blog: http://sanjiva.weerawarana.org/ >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Isuru Udana* >>>>> * >>>>> * >>>>> Senior * >>>>> Software Engineer >>>>> * >>>>> WSO2 Inc.; http://wso2.com >>>>> email: [email protected] cell: +94 77 3791887 >>>>> blog: http://mytecheye.blogspot.com/ >>>>> twitter: http://twitter.com/isudana >>>>> >>>> >>>> >>>> >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 71 536 4128 >>>> Blog : http://kasunpanorama.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks >>> /subash >>> >>> *Subash Chaturanga* >>> Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com >>> >>> email: [email protected] >>> blog: http://subashsdm.blogspot.com/ >>> twitter: @subash89 >>> phone: +9477 2225922 >>> Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 71 536 4128 >> Blog : http://kasunpanorama.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, Apache Member > > UK: +44 207 096 0336 > US: +1 646 595 7614 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > [email protected] > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may have > received this communication in error, please reply to the sender indicating > that fact and delete the copy you received and in addition, you should not > print, copy, retransmit, disseminate, or otherwise use the information > contained in this communication. Internet communications cannot be > guaranteed to be timely, secure, error or virus-free. The sender does not > accept liability for any errors or omissions. > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks /subash *Subash Chaturanga* Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com email: [email protected] blog: http://subashsdm.blogspot.com/ twitter: @subash89 phone: +9477 2225922 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
