cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
Subject Performance issue with Content-ID computation of multipart MTOM/XOP messages
Date Mon, 14 Jul 2014 07:54:09 GMT
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 
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?


Alessio Soldano
Web Service Lead, JBoss

View raw message