docs.javadsl.MqttFlowTest: bidirectional connection may leak actors #468
Comments
raboof
changed the title
While looking into apache#468, I noticed the two failing tests were sharing the same session id, which reminded of apache#456. While in this case the two tests aren't sharing the same session, and I haven't investigated the details of this codebase further, I'm curious to see if the problem remains when we use unique session ids.
While looking into apache#468, I noticed the two failing tests were sharing the same session id, which reminded of apache#456. While in this case the two tests aren't sharing the same session, and I haven't investigated the details of this codebase further, I'm curious to see if the problem remains when we use unique session ids.
While looking into #468, I noticed the two failing tests were sharing the same session id, which reminded of #456. While in this case the two tests aren't sharing the same session, and I haven't investigated the details of this codebase further, I'm curious to see if the problem remains when we use unique session ids.
|
(let's close this for now in case #736 was it, and re-open when it turns out it wasn't) |
Avoid multiple tests using the same topic. Possibly towards avoiding apache#468
|
The problem is that, after the test finishes, there are still Streams components 'in flight', indicating some kind of leak in the stream teardown logic. The component that checks for these remaining running components helpfully products 'dot' graphs to diagnose what is waiting for what. Unfortunately these confuse me even more: it seems even 'headSink' is still waiting for input, even though that component should complete after producing its one and only value (and the test completing suggests that this has already happened). That could use additional research: is the component indeed still running, or is the dot output just confusing? However, while looking at this test again, I noticed that it is still using a topic that is also used in another test. While that doesn't really explain why the components still seem to be running after the test has completed, no good can come of it, so let's make sure those tests are independent with #981. Of course multiple tests sharing the same topic should still not lead to stream components getting left behind - but if making the tests more independent fixes the symptom of these flaky tests that's already a win in my book. |
It seems to be specifically
establishClientBidirectionalConnectionAndSubscribeToATopicandestablishServerBidirectionalConnectionAndSubscribeToATopicThe text was updated successfully, but these errors were encountered: