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
