Return-Path: Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: (qmail 33350 invoked from network); 27 Jun 2008 07:44:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jun 2008 07:44:00 -0000 Received: (qmail 1102 invoked by uid 500); 27 Jun 2008 07:44:01 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 1060 invoked by uid 500); 27 Jun 2008 07:44:01 -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 1049 invoked by uid 99); 27 Jun 2008 07:44:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 00:44:00 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of indika.kuma@gmail.com designates 72.14.246.240 as permitted sender) Received: from [72.14.246.240] (HELO ag-out-0708.google.com) (72.14.246.240) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2008 07:43:11 +0000 Received: by ag-out-0708.google.com with SMTP id 9so1747647agd.2 for ; Fri, 27 Jun 2008 00:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=2GatGZTIY0pakMGtM8axYGgUGUv3SEpSWQtwq7bBZo4=; b=FW/kdNmcb8JeEQ35pvRcwnQ4czVLU3KavKxzU622nM8wZJqE08ygAJTQXB++rYbusV QbcnjIlCvloZBnqN3mFfj9FoPqFB1rGDo8WGWQfR/ejJFRfF8yeiBFXQKfBDvG6iFBC1 1MHEJcBQgfbO3v2DD0PaEAHwxh7aI6MI0844w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=urAnjfRGlkf2/3fnE6qt123AUI2D2THVJHSxmQXahbz71obYkqBObvp4//SPoq7gud M3JOcIG32qkaa5StPcd6/nt+56AeoJCccy5MIBVCDR7YKlVknQL37t1j8gWcxryN4V5t 3xBiUxLX9sS5+7/giUjgoPByJP5PNPj7eZY7k= Received: by 10.110.26.20 with SMTP id 20mr999019tiz.23.1214552608945; Fri, 27 Jun 2008 00:43:28 -0700 (PDT) Received: by 10.110.63.8 with HTTP; Fri, 27 Jun 2008 00:43:28 -0700 (PDT) Message-ID: Date: Fri, 27 Jun 2008 13:13:28 +0530 From: "indika kumara" To: dev@synapse.apache.org Subject: Re: Improving performance even more :) In-Reply-To: <672a01200806260921k4c9a6783lc858df24c8e25c2@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12697_2047213.1214552608944" References: <88f5d710806250743p63239218tc672bb5c882c5132@mail.gmail.com> <672a01200806260728k2de80b59y210bc9637705b05@mail.gmail.com> <88f5d710806260741u79ddf529u7aba815078a932fc@mail.gmail.com> <672a01200806260921k4c9a6783lc858df24c8e25c2@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_12697_2047213.1214552608944 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All Some thought... Currently message building and serializing is in transport layer. According to the content type ,message is being built and we cannot control the building process. For example , if the content type is corresponding to the SOAP , then SOAP message is built and we cannot avoid it. This is fine only if we use or access SOAP message. But if we can dispatch to synapse,proxyservices,etc without touching SOAP message and if we will not touch the SOAP message within synapse, then , we should not want a SOAP message. But , currently , we have not that control . If we can provide a option to transport to specify whether to build a message or not (build and set as SOAP envelope ) and also if can provide a way in synapse language to specify whether to build a message or not(Build mediator which builds message and sets as SOAP envelope =96 default behavio= r may use content-type, but we have to have options to override it.). One other possibility is , with in transport layer , the message always set as stream or OMDatasource (use BinaryBuilder ) irrespective of content type an= d whenever try to access message on the first time (messagecontext.getSOAPEnvelope()) and if SOAP envelope has not been built yet, then builds it and sets as Envelope. This will be completely avoid building message as a SOAP envelope , if we have not any interest in it. For serialization part , we can do the same thing. I don't know this is a good suggestion , but I believe , for scenarios, tha= t we don't access SOPA message, we have to completely avoid building it. Thanks Indika ------=_Part_12697_2047213.1214552608944 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =09 =09 =09 =09

Hi All

Some thought...

Currently message building and serializing is in transport layer. According to the content type ,message is being built and we cannot control the building process. For example , if the content type is corresponding to the SOAP , then SOAP message is built and we cannot avoid it. This is fine only if we use or access SOAP message. But if we can dispatch to synapse,proxyservices,etc without touching SOAP message and if we will not touch the SOAP message within synapse, then , we should not want a SOAP message. But , currently , we have not that control .

If we can provide a option to transport to specify whether to build a message or not (build and set as SOAP envelope ) and also if can provide a way in synapse language to specify whether to build a message or not(Build mediator which builds message and sets as SOAP envelope =96 default behavior may use content-type, but we have to have options to override it.). One other possibility is , with in transport layer , the message always set as stream or OMDatasource (use BinaryBuilder ) irrespective of content type and whenever try to access message on the first time (messagecontext.getSOAPEnvelope()) and if SOAP envelope has not been built yet, then builds it and sets as Envelope. This will be completely avoid building message as a SOAP envelope , if we have not any interest in it.

For serialization part , we can do the same thing.

I don't know this is a good suggestion , but I believe , for scenarios, that we don't access SOPA message, we have to completely avoid building it.

Thanks
Indika

------=_Part_12697_2047213.1214552608944--