Excellent! :-)
On Fri, Oct 4, 2013 at 2:34 PM, Kasun Indrasiri <[email protected]> wrote: > 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 > > -- 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
