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.
Dan On Jul 14, 2014, at 3:54 AM, Alessio Soldano <[email protected]> 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) ? > 3) any different idea / solution? > > Thanks > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
