Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refreshing nodes on interval timer breaks socket.io pubsub adapter #696

Closed
jeremytm opened this issue Sep 14, 2018 · 2 comments · Fixed by #697
Closed

Refreshing nodes on interval timer breaks socket.io pubsub adapter #696

jeremytm opened this issue Sep 14, 2018 · 2 comments · Fixed by #697

Comments

@jeremytm
Copy link

Using socket.io-adapter causes the redis connection to enter subscriber only mode, any other command causes an error, and a reconnect.

Error: Connection in subscriber mode, only subscriber commands may be used

Therefore the ioredis interval timer which refreshes cluster nodes every 5 seconds causes an error, and continual reconnections due to the fact that is runs CLUSTER NODES which is not allowed.

Not sure how to resolve this, given the purpose of the interval – but I thought you should be aware.

luin added a commit that referenced this issue Sep 14, 2018
This fix will skip the subscriber who can't execute
any command.

Close #696
@luin
Copy link
Collaborator

luin commented Sep 14, 2018

A fix (WIP) is here #697. Waiting for tests to be added.

@hhgyu
Copy link

hhgyu commented Sep 19, 2018

If you modify it referring comment, Is there any problem?

#697

luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
luin added a commit that referenced this issue Oct 6, 2018
Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
@luin luin closed this as completed in #697 Oct 8, 2018
luin added a commit that referenced this issue Oct 8, 2018
* fix(cluster): robust solution for pub/sub in cluster

Previously (v3 & v4.0.0), ioredis reuse the existing connection
for subscription, which will cause problem when executing commands
on the reused connection.

From now on, a specialized connection will be created when any
subscription has made. This solves the problem above perfectly.

Close #696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants