Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 74.125.82.172 as permitted sender)
Message-ID: <53C39ECD.7020509@gmail.com>
Date: Mon, 14 Jul 2014 10:11:41 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: Performance issue with Content-ID computation of multipart
 MTOM/XOP
 messages
References: <53C38CA1.7040308@redhat.com>
In-Reply-To: <53C38CA1.7040308@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Alessio
On 14/07/14 08:54, Alessio Soldano wrote:
> Hi,
> while running some performance benchmarks here, we noticed lot of time
> spent computing the content-id of multipart MTOM/XOP messages, which is
> quite unexpected (at least to me). We have a client consuming a wsdl
> which references an external xsd. That xsd contains a type with base64
> encoded data. The schema declares elementFormDefault="qualified",
> attributeFormDefault="unqualified" and
> targetNamespace="org:foo:PurchaseOrder".
> The problem is in AttachmentUtil's createContentID:
>
>      public static String createContentID(String ns) throws
> UnsupportedEncodingException {
>          String cid = "cxf.apache.org";
>          String name = ATT_UUID + "-" + String.valueOf(++counter);
>          if (ns != null && (ns.length() > 0)) {
>              try {
>                  URI uri = new URI(ns);
>                  String host = uri.toURL().getHost();
>                  cid = host;
>              } catch (Exception e) {
>                  cid = ns;
>              }
>          }
>          return URLEncoder.encode(name, "UTF-8") + "@" +
> URLEncoder.encode(cid, "UTF-8");
>      }
>
> If the code inside the 'if' block is executed, a URL is to be created
> from the namespace string, which in my case is something like
> "org:foo:PurchaseOrder" (note, I can't change that, it's part of the
> benchmark sources). Building a URL from a String is potentially very
> expensive, because of the involved URLStreamHandler processing. In my
> case, the method will try to locate a URLStreamHandler named something
> like "xyz.org.Handler", which obviously does not exist; that causes a
> CNFE to be initialized, thrown and caught in the catch block above. That
> badly affects performances.
>
> Now, I have few questions:
> 1) do we really need that mechanism for computing the content-id from
> the host of the url generated using the namespace? is there a spec
> requiring that?
> 2) if that's required, would you mind me trying to add some preliminary
> checks to avoid the URL generation when that's clearly going to raise an
> exception (for instance by parsing the string using a pre-computed
> regular expression) ?

Doing some basic manual checks would be faster indeed. You can simply 
try URI.getScheme and/or URI.getAuthority, and do some basic checks 
around it, no need to convert to URL for sure...

Thanks, Sergey

> 3) any different idea / solution?
>
> Thanks
> Alessio
>