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"/>
> ...
>
>
> 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
