Testing DragonflyDB with Bull

Hey everyone! I’m trying to migrate from Redis to DragonflyDB. I’m using the ioredis and @bull-board/api packages for Redis.

I set up DragonflyDB on port 6380, and ran redis-cli -p 6380 to get into it. I then ran replicaof local 6379, and dbsize showed the correct data. However, I then restarted my app and got met with the error “Failed to handle unlocked job in active”.

What’s the proper way to migrate from Redis to DragonflyDB? I already tried riot-redis to no avail.

@inclusive-numbat apologies for the ping, but I see you’re online ^^;

If you are using bullmq underneath, we do not yet support it. See the open issue in the repo

Ah. Could you point me to the issue?

Ah, nvm. This one? https://github.com/dragonflydb/dragonfly/issues/782

Yep

@inclusive-numbat so, I built from source and used the --default_lua_config=allow-undeclared-keys parameter to get it running. However, it seems that it’s not being utilized efficiently? Is there any tweaking/tuning I can do? I have Dragonfly running on a dedicated 8 core 16GB VPS, but it’s using very little resources and puts many jobs into “waiting” rather than processing them…

@meaningful-vole

Try using --default_lua_config=allow-undeclared-keys,disable-atomicty

but we do not officially support bull, yet

Tell us if it improves things on your end

@inclusive-numbat doesn’t seem to work

I20230601 18:04:00.422749 3223497 init.cc:69] ./dragonfly running in opt mode.
I20230601 18:04:00.423955 3223497 dfly_main.cc:592] Starting dragonfly df-dev-0000000
W20230601 18:04:00.424810 3223497 dfly_main.cc:629] SWAP is enabled. Consider disabling it when running Dragonfly.
I20230601 18:04:00.425529 3223497 dfly_main.cc:632] maxmemory has not been specified. Deciding myself....
I20230601 18:04:00.425748 3223497 dfly_main.cc:636] Found 15.62GiB available memory. Setting maxmemory to 12.50GiB
I20230601 18:04:00.462266 3223504 uring_proactor.cc:158] IORing with 1024 entries, allocated 102720 bytes, cq_entries is 2048
I20230601 18:04:00.494704 3223497 proactor_pool.cc:77] Running 16 io threads
F20230601 18:04:00.494937 3223497 script_mgr.cc:49] Check failed: !err Invalid flag: disable-atomicty
*** Check failure stack trace: ***
    @     0x5590d3620000  google::LogMessage::Fail()
    @     0x5590d36274d7  google::LogMessage::SendToLog()
    @     0x5590d361fa13  google::LogMessage::Flush()
    @     0x5590d36213af  google::LogMessageFatal::~LogMessageFatal()
    @     0x5590d32f7beb  dfly::ScriptMgr::ScriptMgr()
    @     0x5590d3313544  dfly::ServerFamily::ServerFamily()
    @     0x5590d32b41ac  dfly::Service::Service()
    @     0x5590d326164b  dfly::(anonymous namespace)::RunEngine()
    @     0x5590d3258508  main
    @     0x7f05b6741d90  (unknown)
    @     0x7f05b6741e40  __libc_start_main
    @     0x5590d325ce65  _start
*** SIGABRT received at time=1685642640 on cpu 11 ***
PC: @     0x7f05b67aea7c  (unknown)  pthread_kill
[1]    3223497 IOT instruction (core dumped)  ./dragonfly --default_lua_flags=allow-undeclared-keys,disable-atomicty 

When running --help I get this:

 Flags from /server/script_mgr.cc:
    --default_lua_flags (Configure default flags for running Lua scripts:
      - Use 'allow-undeclared-keys' to allow accessing undeclared keys,
      - Use 'disable-atomicity' to allow running scripts non-atomically.
      Specify multiple values separated by space, for example
      'allow-undeclared-keys disable-atomicity' runs scripts non-atomically and
      allows accessing undeclared keys); default: "";
    --lua_auto_async (If enabled, call/pcall with discarded values are
      automatically replaced with acall/apcall.); default: false;

Ah, seems that ./dragonfly --default_lua_flags='allow-undeclared-keys disable-atomicity' --alsologtostderr works

Doesn’t really seem to change anything though…

Actually if anything it seems to have made things slightly worse

https://github.com/dragonflydb/dragonfly/issues/1335

@inclusive-numbat I can give you moderator permissions on my site to view bull-board if you want, if that’ll help with solving issues :slight_smile:

@inclusive-numbat I just noticed something really weird – the Waiting section of my Delivery queue (there’s an Inbox and Delivery queue) just jumped from 0 to 7,000 in a split second, and this never happened on Redis. I wonder if there’s some scheduling issues :worried:
image.png

@winsome-nautilus

  1. Yes, allow-undeclared-keys makes Dragonfly slower, a lot. Scripts that access undeclared keys are unpredictable. Unpredictability and multi-threading don’t mix well :roll_eyes:
  2. Roman forgot an i: its disable-atomicity
  3. Please note that from 1.4.0 the flag will change to default_lua_flags

We have in our plans to check compatibility with Bull and we’ll check your issues. disable-atomicity actually disables atomicity and it means that multiple scripts can operate on the same set of keys at the same time. If the script requires atomicity for correct execution, it won’t work properly in this mode. If you’re not sure, please don’t run them with this mode - it can lead to all kinds of undefined behavior and possible bugs.

We’re happy to see you using Dragonfly. However currently we still have some issues with some of the popular frameworks. We hope it’ll improve in the future :slightly_smiling_face: