Relaunch on error's behavior?

[Mis1eader-dev]

Continuing off from this trantor issue, it seems if drogon has the relaunchOnError option enabled, it interferes with other libraries and causes them to crash, and it completely disables trantor::ConcurrentTaskQueue::runTaskInQueue, which in turn stopped all database operations.

What is the behavior of that option? It interfered with nanomq's concurrency model too once it got turned on, and started causing crashes.

[JaylinYu]

Just being curious, how would drogon interfered with NanoMQ, our parallel computing framework is pure C implemented, not base on drogon.
^_^

nevermind, I guess what you mean is the archived nanomq project

[Mis1eader-dev]

@JaylinYu I have nanomq (my fork) statically linked within the same executable as drogon, and whenever I had nanomq perform a publish message, it crashed and stated something about non reentrant locks or mutexes.

After disabling Drogon's relaunchOnError, it went back to normal

[hwc0919]

relaunchOnError starts a child process using fork.
The parent process monitors the child process, and starts a new one when it dies. The child process runs the framework logics.

The fork syscall may mess up with opened files and sockets. That might be the problem.

[Mis1eader-dev]

Is it normal that it interfered with trantor::ConcurrentTaskQueue::runTaskInQueue?

[hwc0919]

'relaunchOnError ' is not a method that can rescue your program from failing. It acts just like systemd, which will restart the program again when it dies.

Everything will become obsolete after relauching.

When this option is actually triggered, it means your program has fatal bugs in it, and you should find and fix it.

[Mis1eader-dev]

Yeah I'll have to perform some tests to find out if that runTaskInQueue triggers on an empty project.
On the project which this issue occurred the runTaskInQueue function just didn't do anything, with no bugs present in the actual code within the lambdas being ran by runTaskInQueue or the code before and after calling runTaskInQueue.
I'll do the test on an empty project and report back whether it gets called

[hwc0919]

@Mis1eader-dev I misunderstood your situation. I thought you runTaskInQueue stop working after relauching, but actually it never works.

I never use the ConcurrentQueue. It uses a mutex and a conditional variable, and I guess fork may break it.

I sugguest you disable the relaucnOnError and use systemd instead. The side effects of this option is not fully tested against all components.

[Mis1eader-dev]

@hwc0919 do you recommend something different than trantor::ConcurrentTaskQueue for database operations?

[hwc0919]

I recommand to use async or coroutine apis, so you don't need an task queue.

If you are using something that only has sync api, you might need a task queue.

The EventLoopThreadPool should be enough for most cases. It's disadvantages is that workloads of different threads may become uneven if you put lots of jobs with different load in it.

[Mis1eader-dev]

I do use a synchronous database API, namely rocksdb, so trantor::ConcurrentTaskQueue is the right tool for the job I presume.
Will keep this issue open in case other people notice trantor::ConcurrentTaskQueue::runTaskInQueue not doing anything.