RedisPubSubConnectionImpl.activated() deadlock about lettuce HOT 9 CLOSED

I feared, this would happen sooner or later.

from lettuce.

My solution for this was to execute the subscription in a thread. It can be pushed on the Netty loop too I guess.

from lettuce.

I'm wondering whether it is a good idea to introduce a ConnectionOptions class for enabling/disabling reconnects and perhaps how reconnect errors should be handled. This does not solve the problem above but would give a more fine grained control to the user.

from lettuce.

That will be a good place to add that "ping before thinking the connection is alive" I asked for before. This way the SSL tunnel can be verified before being used.

from lettuce.

+1

from lettuce.

I think, removing synchronized from the dispatch() methods should solve the deadlock. The writeLock protects the reconnect sequence from other, interfering commands. Clients invoking commands while channelActive will simply wait until activated() is done.

from lettuce.

I think there is more reason for this synchronized. Another method using it is close() and we probably don't want anything writing while that is happening.

from lettuce.

synchronized on close() is important for that case. close() should be called rarely in comparison to other methods. The only race which could occur is when using MULTI and concurrent threads try to add commands to the MULTI. This is in any case a bad idea - with or without synchronized.

I took a look in the older version code. There was no inner lock and the method level synchronized on dispatch() was intended to prevent races. In certain constellations the commands received responses from earlier commands, therefore the inner lock came into place.

from lettuce.

Fixed with #59

from lettuce.