Replies are inlined below: On Thu, Mar 13, 2014 at 9:40 AM, Matthew MacClary <[email protected]> wrote: > Interesting, so the Java client is just honoring the server's request that > it try back in 60 seconds?
No, again, the timeout is on the Riak side. There is no timing in the client, it's just doing a blocking read on a socket (with no timeout). Riak sends an error message to the client when a timeout occurs and the default behavior of the client is to retry all failed operations. > Do you happen to know if there is a configuration > variable to tune that default timeout value? The operations in the client have an optional timeout to send with the request that will override the default setting on the Riak side for that operation. See: http://basho.github.io/riak-java-client/1.4.4/com/basho/riak/client/operations/FetchObject.html#timeout(int) > Our automated testing since yesterday has shown that changing pb_backlog did > resolve this 60 second timeout issue for our system. If this is the case then it seems what you're talking about isn't related to operation timeouts at all but rather TCP connection timeouts. I do find it odd that the change you made would resolve any sort of TCP timeout issue. AFAIK the pb_backlog is simply how many TCP connections can be queued waiting to be accepted (the same as you would pass directly to the listen() system call). If you performed an operation with the client and it needed to create a new TCP connection to Riak, you would expect the client connection to be refused instantly if the listen queue was full. While the client is going to retry making that connection, it certainly wouldn't take 60 seconds to do so - I'd expect all retries (3, by default) to fail instantly and the client to throw an exception back to you saying it couldn't connect. Connections that were *in* the listen queue I could see causing a TCP connection timeout if Riak never accepted them before the client side's TCP stack gave up, but in my head your change would increase the frequency of that happening rather than reducing it. - Roach _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
