Open alexmherrmann opened 12 months ago
The basic problem here is a mixture of asynchronous mechanisms (futures, and listeners) and then a listener making a synchronous executeRemoteCommand
call.
The immediate cause for blocking is that internally a lock is held, which prevents any more incoming messages for that session being handled until that listener is done. "Fixing" this in a transparent and scalable way inside the library looks very difficult.
A quick work-around for your case would be to make that listener use a different thread for everything after logger.info("Authed: $authed")
.
Version
2.11.0
Bug description
I have not found any examples of what I am trying to do in official documentation.
I have two tests here (in kotlin):
The synchronous one works just fine. I call verify twice and then I am set up to go. However I'm going for an async architecture and would rather do something like the second as it will eventually be integrated into a project reactor application.
The first one runs just fine, the second one hangs forever on the
connected.session.executeRemoteCommand(...)
. Setting a breakpoint it makes it all the way to the second listener (i.e. I get the "Authed: ..." log message) and then never makes it to the "Output: ".Actual behavior
The test fails to complete in any amount of time.
Expected behavior
The
executeRemoteCommand
should executeRelevant log output
Other information
No response