-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Error: Sending custom commands in pipeline is not supported in Cluster mode when use Cluster Mode #758
Comments
ok, seems like it is a limitation of ioredis at least. I did not now about it: redis/ioredis#536 |
@manast we are starting to run into this. Do you know what features specifically require pipelines? Is there some subset of features we can still use without them? |
@manast I'm running in the same issue when calling |
@btzsoft that is because ioredis does not support multi commands using custom lua scripts, and only |
@manast oh no, do you have some plans in future to change this? if no can you give pls some hints where to take a look, maybe I will make a fork and will changes this, bcs it's really a big blocker for us. thank you for your time. |
you can check the implementation of moveToFailed, it is quite inconvenient to not being able to use multi in this case. The other alternative is to convince the authors of ioredis to fix this issue: |
@manast just to better understand, why |
@btzsoft I think you could understand this better if you check the source code, basically it is because moveToFailed has much more functionality such as retries, updating attempts, backoffs, etc. |
@manast Does this mean bull is incompatible with a Redis cluster-mode-enabled cluster until ioredis is enhanced? Is there no workaround? In the meantime, can you update the Patterns doc, which provides a (broken?) example of how to use Redis Cluster? https://github.com/OptimalBits/bull/blob/develop/PATTERNS.md#redis-cluster |
@manast - I am facing same problem. Works with local redis instance. But in our int and prod we use Redis cluster. When a job is added to queue process fails with error 'Sending custom commands in pipeline is not supported in Cluster mode'. Then job stalls. Is there a work around for this issue? It is really urgent for us. Kindly help. |
@manast Can you confirm that this is not an issue in BullMQ? |
@joebowbeer it is the same problem unfortunately. I was expecting ioredis to be fixed but for some reason they did not prioritize it. The alternative is to convert "moveToFailed" method in bull/bullMQ to one lua script, as you can see it is quite a bit of job, but it seems like it is the only way to solve this issue once and for all... will try to prioritize it. |
Are you sure this happens when you add the job and not when the job fails? |
@manast Thanks for prioritizing this! I repo'd the issue in BullMQ as well. |
By using just a single ioredis custom command invocation now, rather than a transaction including a custom command, we should have OptimalBits#758 resolved. Slightly simplified logic (hopefully).
By using just a single ioredis custom command invocation now, rather than a transaction including a custom command, we should have OptimalBits#758 resolved. Slightly simplified logic (hopefully).
Affects the following scripts: - moveToDelayed - moveToFinished - retryJob Allows for the `attemptsMade`, `stacktrace` and `message` fields to be updated through Lua scripts, rather than requiring a separate operation (or multiple operations) to set these fields. With the possibility of setting these fields within the context of a single script, we avoid the need to craft a transaction containing both HMSET and EVAL(SHA) commands to achieve atomicity. By shedding the need for a transaction, we are able to avoid redis/ioredis#536 and thus solve a common problem seen when targetting Redis clusters. This isn’t necessarily an ideal means of solving this problem, given we’re violating DRY principles by copying the same logic across scripts. It’d be ideal if the underlying ioredis restriction was removed (in a manner which doesn’t entail the performance cost of resubmitting scripts each time).
By using just a single ioredis custom command invocation now, rather than a transaction including a custom command, we should have OptimalBits#758 resolved. Slightly simplified logic (hopefully).
Affects the following scripts: - moveToDelayed - moveToFinished - retryJob Allows for the `attemptsMade`, `stacktrace` and `message` fields to be updated through Lua scripts, rather than requiring a separate operation (or multiple operations) to set these fields. With the possibility of setting these fields within the context of a single script, we avoid the need to craft a transaction containing both HMSET and EVAL(SHA) commands to achieve atomicity. By shedding the need for a transaction, we are able to avoid redis/ioredis#536 and thus solve a common problem seen when targetting Redis clusters. This isn’t necessarily an ideal means of solving this problem, given we’re violating DRY principles by copying the same logic across scripts. It’d be ideal if the underlying ioredis restriction was removed (in a manner which doesn’t entail the performance cost of resubmitting scripts each time).
By using just a single ioredis custom command invocation now, rather than a transaction including a custom command, we should have OptimalBits#758 resolved. Slightly simplified logic (hopefully).
Super sorry for the excessive mentions all! (Was doing a bit of cleanup and of course GH has appended to this discussion for every instance of these commits.) That said, if anyone urgently needs this working, a patch can be found in the fpm-git/bull/bug/fix-#758-redis-cluster-breakage branch. Insert the usual "it works for us, but no warranties, etc." spiel here. |
@Rua-Yuki
|
Unfortunately the fix the did on ioredis breaks Bulls unit tests for repeatable jobs, so we cannot use that fix until we discover the reason for the breakage. |
@huxwfun Many thanks for bringing this to my attention! Our use case only demanded a quick fix for the issue raised here with Alternatively, #1933 can be used to get the benefits of
I've just added #1933, which seems to have the repeatable job unit tests all happy and green with Please don't hesitate to let me know if there are any further steps I should take, or anything I might do to help out. Thanks! |
Is this issue resolved by updating the bull and ioredis because it seemed to fix it for me, should this issue be closed and resolved? |
@gurbaj5124871 I am not 100% sure. Maybe somebody else from this thread could verify it before we close. |
When i use bull in redis cluster mode.
Configuration options
Create job it's worked but when i process job with queue.process,
I encounter the following error
Apparently the pipelines are not compatible with cluster mode of redis.
Can you confirm this problem?
How to use bull with a cluster redis without encountering this problem?
The text was updated successfully, but these errors were encountered: