We are building a high-throughput back-end system that will be sending and retrieving variably sized byte[], a cache service. The bindings are critical for this project so we have been testing SOAP, REST, and Fast Infoset and using a Memcached client as our baseline.
Our tests don't reveal any difference between the round trip times of the SOAP and Fast Infoset clients. My messages do not include the header information indicating application/fastinfoset. From what I can see Fast Infoset is not getting turned on because the client is not sending the correct information because the technique in the Metro guide is wrong or there is something I have completely missed.
Am I doing something wrong? Is there a better solution?
There is a solution for the same problem on CXF on this site but it is not one I can use, I am using Metro. Please don't reference that solution to me.
Here is the metro guide on how this should work:
- Glassfish 3.1.2
- jdk 1.7
- Metro 2.2
The two clients in my test are the same accept for one line of code.
((javax.xml.ws.BindingProvider) _port).getRequestContext().put(JAXWSProperties.CONTENT_NEGOTIATION_PROPERTY, "pessimistic");
The client code for the fast infoset client looks like this. (Just subtract the above line and you know what our soap client looks like.) The guide linked above indicates that the above line is all that we need to enable our JAXWS client to use FastInfoset.
public EpCacheFiClient(long period) {
try {
_service = new EpCacheService(new URL(WSDL_URL_KEY), QNAME);
_port = _service.getEpCachePort();
((javax.xml.ws.BindingProvider) _port).getRequestContext().put(JAXWSProperties.CONTENT_NEGOTIATION_PROPERTY, "pessimistic");
if (_port != null) {
System.out.println("Found service port!");
} else {
System.exit(128);
}
} catch (MalformedURLException e) {
e.printStackTrace();
}
}
There is a tutorial from itu which get's into the details of the protocol on the messaging level. In it there is a sample of what my headers should look like.
POST /AlertPort HTTP/1.1
Content-Type: application/fastsoap; action="urn:alert"
Accepts: application/fastsoap, application/text+xml
Content-Length: ....
... sequence of octets …"
The tutorial is from 2005, we know that the HTTP header field Content-Type has changed, it should be application/fastinfoset according to the above metro guide reference. This is evidence that I am not experiencing a bug but rather there is a documentation problem. Hopefully I will find out from the kind experts on this forum.
Here is what my messages looks like. I chopped off the binary. Note the absence of any indication to the service that continued communication with this client should be Fast Infoset. Using Wireshark I can definitively say that none of the messages I sent to my server had any header information to indicate Fast Infoset.
POST /epcache/EpCacheService HTTP/1.1
Accept: text/xml, multipart/related
Content-Type: text/xml;charset=utf-8
SOAPAction: "urn:ProcessEpCacheSet"
User-Agent: JAX-WS RI 2.2.4-b01
Host: linux-xxxxx:8080
Connection: keep-alive
I wanted to note as well that I can put whatever I want into the request context of the BindingProvider and it will show up in the header on every request so there is no problem with instancing _port in my test.
