The new Resource Adapter Config Page doesn't use the REST API correctly. Instead of creating the config, properties and all, in one request, it creates the config, the creates the properties. This causes HUGE delays in processing, as the JMS module seems to reload/restart every time a relevant change to domain.xml is persisted. The way properties are created via the .../property end point results in two domain.xml commits, one for the property key/value, and another for the property description (even if there is none). If the config has, say, 38 properties, as seems to be the default (based on the Console dev tests), that's 76 commits, and 76 JMS reloads/restarts. We're seeing timeouts on this page in our dev tests, even when the timeout is set to 15 minutes.
The fix, then, is to pass the properties as part of the initial create. The diff attach does just that, reducing the page processing time to under 5 seconds. Issue
GLASSFISH-15634 address the performance issue in saving properties, which is still seen, even with this change, when updating the config.
How bad is its impact? (Severity)
Severe. This page is completely unusable for anything beyond the most basic of configurations.
How often does it happen? (Frequency)
How much effort is required to fix it? (Cost)
Half a day's work
What is the risk of fixing it? (Risk)
There is the risk, of course, of introducing new bugs into the page, since we're changing how the config is created, but we have tests already written to help prevent that.
Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Not that I know of.
If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?