[MAGNOLIA-8412] InstanceAlreadyExistsException when registering MBean Created: 12/May/22  Updated: 10/Jan/24  Resolved: 15/Nov/23

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 6.3.0
Fix Version/s: 6.3.0

Type: Bug Priority: Neutral
Reporter: Michael Duerig Assignee: Quach Hao Thien
Resolution: Fixed Votes: 0
Labels: dx-core-6.3
Remaining Estimate: Not Specified
Time Spent: 3.5h
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[X]* Steps to reproduce, expected, and actual results filled
[X]* Affected version filled
Epic Link: 6.3 Consolidation
Work Started:
Approved:
Yes

 Description   

ReloadConfigCmdRegistration and ConfigWorkspaceJmxRegistration fail to register the MBean on public when an author is already running in the same container (i.e. in our integration tests):

Caused by: javax.management.InstanceAlreadyExistsException: info.magnolia.microprofile:type=config,name=ReloadConfigCommand
	at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
	at info.magnolia.objectfactory.guice.microprofile.mxbean.ReloadConfigCmdRegistration.registerMXBean(ReloadConfigCmdRegistration.java:57)

Workaround

workaround that logs these errors instead of throwing a runtime exception is in place.

Implementation note

(Note from aichimescu copied over from Slack )

"The ReloadConfigCmdMXBean is responsible for reloading the microprofile configuration without restarting the instance. In Saas, the config files are being watched by the vitals, and if a change is detected, we trigger a refresh.

The ConfigWorkspaceJMXBean is responsible for locking/unlocking the config workspace. Locking is being triggered at startup. We should not need this bean in dx-core since we don't need to lock or unlock the jcr workspace.

As for suggestions, since I am not a fan of using the jmx for this, I would convert the mxBeans to rest-endpoints that are only visible to the sys-admins. For reloading the microprofile config, this implies a change in the vitals-webapp as well in order to properly form the base-url (but I think that we have the subscription-id as a param)."

 


Generated at Mon Feb 12 04:32:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.