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-2507: fixes rar deployments wrt register's leaks #5650
Conversation
Build 2081 is now running using a merge of 808be05 |
Build 2081 outcome was SUCCESS using a merge of 808be05 |
Build 2084 is now running using a merge of 9866437 |
Build 2084 outcome was SUCCESS using a merge of 9866437 |
@maeste is this ok? |
} catch (Throwable e) { | ||
// ignore | ||
} | ||
if (!activation) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong because Inactive service should always be created. The common use case needs always an inactive service:
- Add a module containing rar
- Add a resource-adapter and activate it. It will create INACTIVE_RESOURCE_ADAPTER_SERVICE and RESOURCE_ADAPTER_DEPLOYER_SERVICE. First one containing only metadata from rar (module) itself, while the second one start the runtime service ResourceAdapterService merging those metadatas to ones provided in resource-adapter
- Add and activate another one resource-adapter using the same module. It will not deploy module rar (there are check above this change to avoid this and so RESOURCE_ADAPTER_DEPLOYER_SERVICE...even if we could have a bug on INACTIVE_RESOURCE_ADAPTER_SERVICE in this case), and when you activate it will use inactive-rar service metadatas, merge its own and start the runtime ResourceAdapterService
- User change config on an already defined resource-adapter and call :activate again on this. The runtime ResourceAdapterService is stopped (and service removed) and use inactive-rar service merging its own new metadata and starting runtime ResourceAdapterService
Moreover you are saying that the root cause of the problem is that in some case resource-adapter is already activated before explicit call to :active. It would possible only if ResourceAdapterDeploymentService.AS7RaDeployer#checkActivation return true, and it's possible from module because ironjacamar.xml is not considered (internal file forcing activation of a rar) and there is an explicit check there about pure inflow rar to don't activate automatically it if they come from module w/o
Feel free to ping me on IRC to discuss the issue and finding a solution
ok, thanks for the clarifications about the inactive service and the activation management operation, let me look at the code again and think a bit about it, I will then ping you on IRC to discuss a solution. The other fixes about RA state cleanup are not truly related to this, are you fine with these? |
Build 2354 is now running using a merge of ac75816 |
Build 2354 outcome was SUCCESS using a merge of ac75816 |
Build 2355 is now running using a merge of e983869 |
The new PR just fixes the leaking of RA registrations in the MDR and RA Repositories, since the duplicated RA activation was fixed elsewhere. On my tests with the JCA basic integration tests I did not observe any leak in both repositories. |
Build 2355 outcome was FAILURE using a merge of e983869 Build problems:Failed tests detected
Failed tests
|
retest this please |
Build 2357 is now running using a merge of e983869 |
Build 2357 outcome was SUCCESS using a merge of e983869 |
@maeste can you look this latest version over? |
I'm fine w/ this one |
WFLY-2507: fixes rar deployments wrt register's leaks
No description provided.