Return-Path: X-Original-To: apmail-synapse-dev-archive@www.apache.org Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 002A5109DD for ; Fri, 18 Oct 2013 19:55:52 +0000 (UTC) Received: (qmail 63251 invoked by uid 500); 18 Oct 2013 19:55:51 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 62919 invoked by uid 500); 18 Oct 2013 19:55:46 -0000 Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@synapse.apache.org Delivered-To: mailing list dev@synapse.apache.org Received: (qmail 62298 invoked by uid 99); 18 Oct 2013 19:55:44 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2013 19:55:44 +0000 Date: Fri, 18 Oct 2013 19:55:44 +0000 (UTC) From: "Hiranya Jayathilaka (JIRA)" To: dev@synapse.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (SYNAPSE-975) Non blocking Callout Mediator (Call Mediator) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SYNAPSE-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799456#comment-13799456 ] Hiranya Jayathilaka commented on SYNAPSE-975: --------------------------------------------- I've just started to review this. My first question is, why do we need another send mediator? We already have two mediators that enable sending messages out. Introducing a third option might increase the level of confusion. Is there a way to somehow unify this work with the existing callout mediator? The issue description says that it's difficult to create chaining sequences with the existing send mediator. This used to be the case, but I think the responseSequence option introduced lately addresses this issue for a great extent. Given that, what problem does this new mediator solve? In any case, I'd prefer to spend some time on reviewing this. Since it involves several changes to the mediation engine, we need to figure out exactly what we want to achieve with this.Hope that's ok with you Isuru. > Non blocking Callout Mediator (Call Mediator) > --------------------------------------------- > > Key: SYNAPSE-975 > URL: https://issues.apache.org/jira/browse/SYNAPSE-975 > Project: Synapse > Issue Type: New Feature > Reporter: Isuru Udana Loku Narangoda > Assignee: Hiranya Jayathilaka > Attachments: sample440.patch, SYNAPSE-975v2.patch, synapse-configs-for-integration-tests.zip > > > One of the major drawbacks in Callout mediator is, it does not leverage the non-blocking transports. > Send mediator which leverages the non-blocking transports, does not provide a simple way to implement service chaining scenarios. > Idea of the the Call Mediator is to solve the above two concerns. > Call Mediator invokes the backend service in an asynchronous manner and return without waiting for the response. > Mediation will be paused from that point. > When response is received, mediation flow resumes from next mediator placed after the Call Mediator. > User will experience two major features with the Mediator. > * Service chaining scenarios will be much easier to implement. > * Since both request and response can be handled within a single sequence, can define reusable sequences. -- This message was sent by Atlassian JIRA (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org For additional commands, e-mail: dev-help@synapse.apache.org