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
