New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WFLY-4016 WFLY-4017 EJB context selector fixes #6870
Conversation
Linux Build 5336 is now running using a merge of dd51cbc |
Linux with security manager Build 329 outcome was FAILURE using a merge of dd51cbc Build problems:Failed tests detected Failed tests
|
dd51cbc
to
873e6a5
Compare
Windows Build 444 outcome was FAILURE using a merge of 873e6a5 Build problems:Failed tests detected Failed tests
|
Linux Build 5336 outcome was FAILURE using a merge of 873e6a5 Build problems:Failed tests detected Failed tests
|
Linux Build 5339 is now running using a merge of 873e6a5 |
Windows Build 447 outcome was FAILURE using a merge of 873e6a5 Build problems:Failed tests detected Failed tests
|
Linux Build 5339 outcome was FAILURE using a merge of 873e6a5 Build problems:Failed tests detected Failed tests
|
I was seeing this test fail when running the EAP test. It seemed to happen via the DescriptorBasedEJBClientContextService change to call localEjbReceiver.stop(context), I have been looking seeing if localEjbReceiver should have stop called, but to close some other objects, but I have been unsuccessful. Without localEjbReceiver.stop(context) we are still seeing references to the deployment's classloader for each time it was deployed. org.jboss.as.test.integration.ejb.remote.byreference.RemoteInvocationByReferenceTestCase.testPassByReferenceSemanticsOnRemoteInterface: java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:in-vm-remote-interface-pass-by-reference-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@16c0899 |
873e6a5
to
89fd375
Compare
Linux Build 5361 is now running using a merge of 89fd375 |
Windows Build 468 outcome was FAILURE using a merge of 89fd375 Build problems:Failed tests detected Failed tests
|
Linux Build 5361 outcome was FAILURE using a merge of 89fd375 Build problems:Failed tests detected Failed tests
|
…service This allows components to have proper dependencies setup, and also removes problems with using the ServiceRegistry directly from a DUP, as the relevant services may not have been started
89fd375
to
150db73
Compare
Linux Build 5388 is now running using a merge of 150db73 |
Windows Build 491 outcome was FAILURE using a merge of 150db73 Build problems:Failed tests detected Failed tests
|
Linux Build 5388 outcome was SUCCESS using a merge of 150db73 |
This actually seems to be working now, @bmaxwell can you verify that this still fixes the leaks you are seeing? |
@stuartwdouglas working on the test now |
@stuartwdouglas SELECT module.identifier.name.value.toString() FROM org.jboss.modules.ModuleClassLoader |
Here is what I'm seeing with the commits from this PR. DescriptorBasedEJBClientContextService still seems to be holding it.
|
Looks like the underlying issue is that there is no corresponding disassociate() call for org.jboss.ejb.client.EJBReceiver#associate |
I think this PR is still valid, as it fixes some other issues, however there are still some fixes needed in the EJB client code. I don't think the original approach of closing the receiver is valid, as the receiver is shared. |
I think I found the changes needed, though not sure about a couple of things.
wildfly / jboss needs to: A quick test shows contexts.remove in the LocalEjbReceiver fixes the memory leak org/jboss/as/ejb3/remote/LocalEjbReceiver |
WFLY-4016 WFLY-4017 EJB context selector fixes
No description provided.