[XNIO-385] Ensure that the close method waits until the server key ca…

[yersan]

…ncellation releases the resources

Jira issue: https://issues.redhat.com/browse/XNIO-385
3.x PR: #249

[dmlloyd]

Looks good, but it should be tested in integration with a WildFly build before merging.

[yersan]

There are issues with the wildfly test suite with this upgrade. This test gets stuck:
https://github.com/wildfly/wildfly-core/blob/e586ab8c23763d54f11be6db75de894b126e5c1f/protocol/src/test/java/org/jboss/as/protocol/mgmt/RemoteChannelManagementTestCase.java#L142

Removing the change on NioSocketStreamConnection.java makes it pass. I've been unable to understand the reason why it gets stuck. It is a random error.

@dmlloyd the fact of being this specific change tells you something about the reason?

This is the output with TRACE level: https://gist.github.com/yersan/88729bd0b7fdedf76c3898321052a0c8

[yersan]

@dmlloyd WildFly and WildFly core TS pass if we don't apply the change on the NioSocketStreamConnection.

What's your opinion if we apply the change only for NioTcpServer.java , this is the one that causes the initial issue. Or, alternatively, allow the client to explicitly close the resources passing the block argument, so we can use in our testsuite and workaround the original issue

[dmlloyd]

@dmlloyd WildFly and WildFly core TS pass if we don't apply the change on the NioSocketStreamConnection.

What's your opinion if we apply the change only for NioTcpServer.java , this is the one that causes the initial issue. Or, alternatively, allow the client to explicitly close the resources passing the block argument, so we can use in our testsuite and workaround the original issue

Let's just apply it to NioTcpServer. Letting the user specify an argument like this will probably lead to hangs and other problems.

[yersan]

Ok, thank you, I'll update the PR and paste here the links of the Jobs

[yersan]

David, as you commented on https://issues.redhat.com/browse/WFCORE-5386, this change is a little tricky, sadly, I am still getting random errors on RemoteChannelManagementTestCase, these are a couple of Jobs that test the integration with WildFly:

https://ci.wildfly.org/viewLog.html?buildId=263711&buildTypeId=WF_WildFlyCoreIntegrationExperiments
https://ci.wildfly.org/viewLog.html?buildId=263708&buildTypeId=WF_WildFlyCoreIntegrationExperiments

Other Jobs outside of the WildFly infrastructure
https://github.com/yersan/multi-repo-ci/actions/runs/1023137981
https://github.com/yersan/multi-repo-ci/actions/runs/1027071778
https://github.com/yersan/multi-repo-ci/actions/runs/1027078111

Sadly, due to the results and its random nature, we should not go with this patch, and we have to find an alternative to avoid hit it in our testsuite.

@dmlloyd If you agree and you have no other suggestions, feel free to close these PRs as an acknowledgment of the situation.

[dmlloyd]

I don't have any other ideas for the moment, unfortunately.