Skip to main content

Fast Infoset comparison to SOAP not faster

2 replies [Last post]
Joined: 2012-09-11

We are building a high-throughput back-end system that will be sending and retrieving variably sized byte[]. 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. It was my expectation that Fast Infoset would improve the transmission times.

Am I doing something wrong? Is there a better solution?
Here is a quickie on how I though it would work:

Glassfish 3.1.2
jdk 1.7

Our client:
The two clients are the same accept for one line of code.

(( _port).getRequestContext().put(JAXWSProperties.CONTENT_NEGOTIATION_PROPERTY, "pessimistic");

It is my understanding that including that line of code with my client will enable Fast Infoset protocol between the client and the service. Below is the Fastinfo Set client. You can imagine the regular SOAP client without the above line of code.

public EpCacheFiClient(long period) {
try {
_service = new EpCacheService(new URL(WSDL_URL_KEY), QNAME);
_port = _service.getEpCachePort();
(( _port).getRequestContext().put(JAXWSProperties.CONTENT_NEGOTIATION_PROPERTY, "pessimistic");

if (_port != null) {
System.out.println("Found service port!");
} else {
} catch (MalformedURLException e) {

I captured a fragment of the POST. On page three of : it idendifies the Accept: as requiring

"POST /AlertPort HTTP/1.1
Content-Type: application/fastsoap; action="urn:alert"
Accepts: application/fastsoap, application/text+xml
Content-Length: ....
... sequence of octets …"

but what I get is.

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-pcootey:8080
Connection: keep-alive
Content-Length: 947911

<?xml version="1.0" ?><S:Envelope xmlns:S=""><S:Body><ns2:processEpCacheSet xmlns:ns2="" xmlns:ns3=""><id>710720</id><data>xECk7+9W

Here is the service code. We use the same endpoint on the instruction that the client will engage the Glassfish server in using Fastinfo set, which is supposed to be on by default.

@WebService(name = "EpCache", serviceName = "EpCacheService", portName = "EpCachePort", targetNamespace = "")
public class EpWsCacheService {

private IServiceLogger _logger;

private IEpService _epCacheService;


* @param cacheItemId
* @param cacheItemData
* @return
* @throws EpServiceException
@WebMethod(operationName = "processEpCacheSet", action = "urn:ProcessEpCacheSet")
public String processEpCacheSet(
@WebParam(name = "id") String cacheItemId,
@WebParam(name = "data") byte[] cacheItemData)
throws EpServiceException {

String epCacheItemId = null;
try {
epCacheItemId = _epCacheService.asyncSetRequest(cacheItemId, cacheItemData);
} catch (Exception e) {
"Error calling syncGet() for cacheItemId {0}. {1}",
new Object[] { cacheItemId, e.getMessage() });

throw new WebApplicationException(e,
return epCacheItemId + " added to cache!";


Finally here is our data random generator.

Random rand = new Random( seed );
//Test 100,000 requests
for(int i = 0; i != requests; i++){
int randomNum = rand.nextInt(max - min + 1) + min;

byte[] byteArray = new byte[randomNum];

Random randBytes = new Random();

// set cache item
long time = -1;
time = sgcI.measureSet("" + randomNum, byteArray);//abstraction on service call
setResults.put(randomNum, time);

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-01-25


I think the problem comes from client side, where depending on jax-ws library you use (if it's embedded into JDK or not) you have to specify different property name to enable fast-infoset.
If you use jax-ws embedded into JDK, pls use this property [1], otherwise try [2]. For example for JDK embedded jax-ws the code will look like:
(( _port).getRequestContext().put("", "pessimistic");

The first HTTP request on wire will look like:

POST /FastInfosetTest/ByteArrayService HTTP/1.1
Content-type: text/xml;charset="utf-8"
Soapaction: "http://bytearray/ByteArrayService/postRequest"
Accept: application/fastinfoset, text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: JAX-WS RI 2.1.6 in JDK 6
Host: localhost:8080
Connection: keep-alive
Content-Length: 201

The proper fast-infoset content-type is application/fastinfoset. The content-type application/fastsoap is related to fast webservices. fast webservices != fastinfoset ;)

Looks like in your usecase you try to transfer huge amount of binary data, even though I'd expect FastInfoset to perform faster than plain XML... it's not the main FastInfoset usecase.
On other hand FastInfoset may outperform XML greatly when you transfer XML documents (not binary data).




Joined: 2012-09-11

Yup that was it. I changed it to [1] and it switched on.

Wish this could have been clearer in the docs. I'll dig around to see if I can submit a request to get this in the documentation. I don't think they should be recommending using JAXWSProperties. JAXWSProperties has been deprecated since I think 2010.

If it's not too much hastle I'll post the test results so folks can see what the difference was for sending huge amounts of binary.

Thanks a million.