java client: overload leads to BlockingOperationException

Henning Verbeek hankipanky at
Wed Jul 13 10:03:15 EDT 2016

I'm still struggling with a BlockingOperationException thrown by
riak-java-client 2.0.6, which occurs when I put heavy load on Riak KV.
Since is fixed,
this happens only in - what I assume is - an overload-scenario.

The exception:

2016-07-13 14:41:12.789  localhost [nioEventLoopGroup-2-2] ERROR
com.basho.riak.client.core.RiakNode - Operation onException() channel:
id:237445453 localhost:8087 {}
DefaultChannelPromise at 77ccd827(incomplete)
        at io.netty.util.concurrent.DefaultPromise.checkDeadLock(
        at io.netty.util.concurrent.DefaultPromise.await(
        at com.basho.riak.client.core.RiakNode.doGetConnection(
        at com.basho.riak.client.core.RiakNode.getConnection(
        at com.basho.riak.client.core.RiakNode.execute(
        at com.basho.riak.client.core.DefaultNodeManager.executeOnNode(
        at com.basho.riak.client.core.RiakCluster.execute(
        at com.basho.riak.client.core.RiakCluster.execute(
        at com.basho.riak.client.api.commands.kv.StoreValue.executeAsync(
        at com.basho.riak.client.api.commands.kv.UpdateValue$1.handle(
        at com.basho.riak.client.api.commands.ListenableFuture.notifyListeners(
        at com.basho.riak.client.api.commands.CoreFutureAdapter.handle(
        at com.basho.riak.client.core.FutureOperation.fireListeners(
        at com.basho.riak.client.core.FutureOperation.setComplete(
        at com.basho.riak.client.core.RiakNode.onSuccess(
        at com.basho.riak.client.core.netty.RiakResponseHandler.channelRead(
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(
        at io.netty.handler.codec.ByteToMessageCodec.channelRead(
        at io.netty.util.concurrent.SingleThreadEventExecutor$
        at io.netty.util.concurrent.DefaultThreadFactory$

Then shortly thereafter:

2016-07-13 14:41:12.820  localhost [nioEventLoopGroup-2-2] ERROR
com.basho.riak.client.core.RiakNode - Write failed on RiakNode
localhost:8087 id: 237445453; cause: {}
java.nio.channels.ClosedChannelException: null
2016-07-13 14:41:12.843  localhost [nioEventLoopGroup-2-2] ERROR
com.basho.riak.client.core.RiakNode - Write failed on RiakNode
localhost:8087 id: 237445453; cause: {}
java.nio.channels.ClosedChannelException: null

The result is a hanging thread, never returning from the call to
`RiakClient.execute()`. It would be great, if in such a case, the
client threw a RiakException (as javadoc says).

But in the meantime, I'm trying to avoid getting into this scenario in
the first place, by sizing the maxConnections of RiakConnector and my
applications frontend threadpools appropriately. My current
observation is this: If I set RiakConnector.withMaxConnections() too
small for the given load (let's say 100), I get the
BlockingOperationException, although according to my (potentially
unprecise connection monitoring), the threshold is never reached.
Setting maxConnections to a higher value (let's say 160) lets the
loadtest run through fine, with around 110 active connections to Riak.

It seems that in order to avoid the BlockingOperationException, I must
set the maxConnections limit higher than what I'll need. Maybe I
should skip maxConnections altogether then, and leave it at 0? But
then, how do I protect against an overload scenario? How many active,
busy connections does Riak KV support? I'm pretty sure the answer to
that is "it depends...".

Thanks for your input.
My other signature is a regular expression.

More information about the riak-users mailing list