cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Performance issue with Content-ID computation of multipart MTOM/XOP messages
Date Mon, 14 Jul 2014 12:57:34 GMT

I’m not aware of anything that would require this at all.   Looking at the logs (I had to
go back to the SVN repo for this), this seems to have been part of the original sets of imports
way back in 2006 done by Dan Diephouse.   Thus, it’s likely something that came from XFire.


On Jul 14, 2014, at 3:54 AM, 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 = "";
>        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 "", 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) ?
> 3) any different idea / solution?
> Thanks
> Alessio
> -- 
> Alessio Soldano
> Web Service Lead, JBoss

Daniel Kulp -
Talend Community Coder -

View raw message