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