On Wed, Aug 28, 2013 at 10:49 PM, Subash Chaturanga <[email protected]> wrote:
> 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=""/>. > We are not dropping this functionality. So he can still use it if he want. > 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. > Apart from that, since both request and response can be handled within a single sequence, we can define reusable sequences. > +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 > > -- *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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
