Option to issue GET in parallel

[matsken]

First of all, thanks for creating this package - this is a perfect fit for our use case where we have two endpoints, each configured with Sentinel cluster but sometimes one of them goes down for maintenance. With this package, we can configure and forget about switching endpoints during maintenance.

Question/problem
If I understand correctly, GET commands are executed in series. So if there are two instances and the first instance is down, the GET command will not get sent to the 2nd one until the first one times out (after childCommandTimeout value).

Then we have a situation where, when the first instance is down, all GET commands will take an additional X time to complete, where X is childCommandTimeout value. This was quite apparent when used with redis session store, where all http requests were taking 10+ seconds.

Describe the solution you'd like
I would like to have an option where, if set to true, run the GET (or any) command in parallel if possible. In the case of a GET command, it will simply issue the command to all clients and respond with the first non-error result. Even if the results were different among the clients, I would be ok with that.
I imagine that it would not be too hard to implement a global option to simply issue all commands in parallel (override the runInSequence flag if set). What do you think?

[sagiegurari]

sounds like a good idea. will try to set it up as an option during the create.

[sagiegurari]

published new version with option: forceParallel so you force parallel for all commands.
this would increase the load on your redis servers i guess.
try it out and tell me if it works good for you

[matsken]

@sagiegurari Thanks! will try the new version.

[matsken]

@sagiegurari I've found that using async.parallel still waits for all async calls to finish (either with a value or an error) which is not desirable. Could we use async.race? With childCommandTimeout set to a sufficiently large value where it is greater than the non-error commands, I think we are ok.

[sagiegurari]

you are right. i'll check it out.

[sagiegurari]

updated version. hopefully this one should resolve the issue.

[sagiegurari]

@matsken did you verify?

[matsken]

@sagiegurari Sorry about the delay in response. I did try the latest version out but it did not seem to work as intended. It still seems to wait for all clients to respond with a result.

[sagiegurari]

are you sure you are passing the new flag?
i have a test (https://github.com/sagiegurari/multiple-redis/blob/master/test/spec/multiple-redis-spec.js#L850) specifically to test this and it would fail if it had to wait for all clients to finish.