Although there are major changes at mediation engine level, we hardly find any issues related to that. Call mediator very stable! This was extremely useful in all Cloud Connectors and unlike callout, we mange to implement connectors without adding any perf overhead. Great job!
On Wed, Aug 28, 2013 at 11:21 PM, Isuru Udana <[email protected]> wrote: > > > > 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 > > -- 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
