Re: Exception on get method clusterj

[Craig Russell]

Based on your report I took a closer look at the handling of charset encoder and decoder. I found a similar multi-thread issue with encoding as well.

There are a few ways to make the code thread-safe and I wrote a micro-benchmark to test them out.

- synchronize access to a static (singleton) decoder
- get a new decoder from charset for each request
- use the decode method in charset
- pool decoders in a thread-safe queue

Here's the code snippet:
switch(strategy) {
case SYNC:
synchronized(charsetDecoder) {
result = charsetDecoder.decode(byteBuffer);
}
break;
case NEW:
CharsetDecoder newCharsetDecoder = charset.newDecoder();
result = newCharsetDecoder.decode(byteBuffer);
break;
case METHOD:
result = charset.decode(byteBuffer);
break;
case POOL:
CharsetDecoder pooledCharsetDecoder = pool.poll();
if (pooledCharsetDecoder == null) {
pooledCharsetDecoder = charset.newDecoder();
}
result = pooledCharsetDecoder.decode(byteBuffer);
pool.add(pooledCharsetDecoder);
break;
}

Before reading on, see if you can figure out which strategy performs best.

The lowest performing strategy is synchronize.

The next worst is pooling decoders by the "application".

Looking good is getting a new decoder for each request and letting the system garbage collect it after use.

The best strategy by far is using the decode method of charset which internally creates a new decoder but can optimize it by caching decoders internally.