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
