r2d2 to pool LDAP connections. Due to
oxide-auth not supporting
async yet, I'm forced to use blocking version of
ldap3 API. I'm using
tokio::task::spawn_blocking() to call the code that uses the connection to avoid tokio panicking with: "Cannot start a runtime from within a runtime."
The pool is created in
tokio::main() and when the program ends, I'm hit with the panick and the backtrace shows me that it's when the LDAP connections are drop. Which makes sense because the sync connection have a tokio runtime in them which seems to block.
This situation is temporary while waiting for proper async support by oxide-auth, but in the meantime I'd like to avoid the panick because it hides the cause of exiting the program (using
Is there anyway to achieve that?
It is not possible to block in the destructor while inside the Tokio runtime, besides stuff like spawning a thread, doing the blocking there, and joining on that thread, which is super ugly. Tokio makes it difficult for a reason.
I understand the reasons I was hoping for a trick to have the
bail! message to be printed before the panicking.
I guess to add logs before the
bail! in the meantime
Ah, so you're seeing aborts because of double-panics?
When I either bail out or reaching the end of
main() (by hitting Ctlr-C to quit gracefully), I have this:
thread 'main' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', C:\Users\geobe\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.21\src\runtime\enter.rs:38:5
And I lose the
And should I be concerned about the connections not being properly closed then?
I don't know when your ldap thing closes the connections.
Even if it was before the panick, as the pool has multiple connections, only one will be closed…
I need to get oxide-auth async support finished, it would solve may issues…
If your program aborts while there are open connections, they will not be closed. I can say that much.
Not in an orderly manner, but the kernel will reap all open file descriptors and force-close the connections.
LDAP servers are not particularly sensitive to abrupt client connection loss. In a protocol exchange, a complete modification message must be received before any change, and atomicity is guaranteed with entry-level granularity, so partial modification is not an issue (multiple-entry changes are another matter). An operation result message may be lost.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.