Use channel thread to enqueue commands

[mp911de]

Using the channel thread to write the command makes a lot of sense because we could probably get rid of some synchronization code and subsequent channel I/O does not require further context switching. It would also unblock writes because we don't require synchronization to perform the actual channel write.

[nikolayk812]

Too me it is more a like bug. I want invoke Lettuce CompletableFuture API and not to worry of caller thread being locked or catch an exception.

Is thrown in caller thread even though CompleteableFuture API is used.

com.lambdaworks.redis.RedisException: Request queue size exceeded: 500. Commands are not accepted until the queue size drops.

[mp911de]

Any validation happens beforehand to fail fast. It does not make sense to accept a command and reject it later if the validation can happen early.

[nikolayk812]

Yes, fail-fast is good, but it should be wrapped in RedisFuture, then I handle it in CompletableFuture.

[nikolayk812]

Otherwise I have to handle exceptions in CompletableFuture and in caller thread. And getting exception in caller thread is counterintuitive.

[mp911de]

There's a point in handling failures inside the callbacks. Thanks a lot for your feedback.

I'd argue that you nevertheless need to handle errors in your call chain anyway – exceptions can happen due to other reasons before the actual command was constructed and dispatched (e.g. argument validation, infrastructure failures).

[nikolayk812]

As API user I would never prefer to get exceptions in caller thread.

All other exceptions could be caught or wrapped by the API implementation and return as CompletableFuture.

[mp911de]

We refactored how exception signals are propagated into RedisCommand objects if a command is not eligible for being written to Redis. Previously, we relied on throws. As of Lettuce 6, we're propagating the failure via completeExceptionally(…) so the calls to async/reactive API's no longer need to care about handling exceptions with a separate approach.