RedisClusterConnection stops operation after .RedisCommandTimeoutException about lettuce HOT 11 CLOSED

Ok, I see the problem now, but not sure how this happens. In CommandHandler:118

        while (!queue.isEmpty() && rsm.decode(buffer, queue.peek(), queue.peek().getOutput())) {

The queue is NOT empty. On the next time through after I break the connection via the UTF8Decoder pause, it has 2 things in it.
Head of the queue is my original clustercommand
Command [type=HGETALL, output=null]
Next in queue is the one I just retried
Command [type=HGETALL, output=MapOutput [output={}, error='null']]

rsm.decode is getting a null output, but returning false, which is exiting the while loop, abandoning my command that I just sent in.

Inverting the return at RedisStateMachine:81 to

        if (output == null) {
            return !stack.isEmpty();
        }

Sort of solves this problem(future commands work to that key). The old command is taken from the queue, completed, and loops over again, sending the result to my real command. But I haven't dug through RSM too much. I think the queue in CommandHandler should be removing the timed out Commands when they time out. Is that the intention of the above stack.isEmpty?

Also, with that small hack above, isMoved() in ClusterCommand NPEs due to otput being null. That could probably be checked for.

from lettuce.

e5fbd1e has a patch that makes it not freeze. However, like I said above, I have no idea if this breaks other things.

from lettuce.

Have a simple test case that reproduces this on standalone and cluster.
a80dfdd

from lettuce.

Hi @taer I'll take a look on this.

from lettuce.

@mp911de Think I found a solution(and updated the test as well) The inversion of that line in RSM is definitely incorrect.

I pushed a new version of BreakServer(should be called breakClient) bd5227f . The fix is 3e20467

from lettuce.

You're faster than me. Would you like to create a PR that contains the fix and the cluster setup (your test perhaps makefile-changes as well)?

from lettuce.

Sure. I'm updating the test now to fit with the rest of the integration tests. And am putting it someplace sane.

Since the command fix fixed both(standalone and cluster), and cluster setup in a test is much more prone to errors, I removed the cluster part.

from lettuce.

There is a Cluster setup rule (JUnit Test Rule) (see existing cluster tests) which might help you

from lettuce.

Can I close this issue after #43 is merged?

from lettuce.

It satisfies this case. I don't see if breaking anything else. I don't see it causing leaks, since if there is an output, the command will be taken from the queue in CommandHandler.java, GCing both.

from lettuce.

Closing, everything is fine. Thanks @taer

from lettuce.