JMX persistence issues

[ivelin.ivanov]

From Dimitris:
- The way XMBean persistence is implemented seems to be faulty. When save() is called the data to be persisted are one step back from the latest update. There maybe some way to hack around this, otherwise the internal APIs need to be changed, and this may be a problem.
- While testing I also found a lot of strange behaviour with settings to the XMBean persistence like update NoMoreOtherThan, etc. I would guess those facilities are not really tested/used. If people start to use XMBean persistence with the new persistence manager, bugs will probably arise there.

[dimitris]

Just to make it more clear:

XMBean are based on AbstractMBeanInvoker. When a setAttribute() call is fielded, the invocation context is set, then the invocation is executed and finally the attribute descriptor is updated in the context and the model mbean info:

...
 // create the invocation object
 Invocation invocation = new Invocation();

 // copy the server context to the invocation
 invocation.addContext(ctx);
...
 try
 {
 // the default invocation implementation will invoke each interceptor
 // declared in the invocation context before invoking the target method
 invocation.invoke();
 }
...
 finally
 {
 /* Obtain the updated attribute descriptor and propagate to the
 invocation context and ModelMBeanInfo. The latter is required in
 order for getMBeanInfo() to show an updated view. Also required
 so that interceptor updates to the attribute descriptor
 (e.g. cached values, update timestamp) are propaged, too.
 */
 Descriptor attrDesc = invocation.getDescriptor();
 ctx.setDescriptor(attrDesc);
 ModelMBeanInfoSupport minfo = (ModelMBeanInfoSupport) info;
 minfo.setDescriptor(attrDesc, ModelMBeanConstants.ATTRIBUTE_DESCRIPTOR);

The problem is that when the PersistentInterceptor decides to call store(), (because e.g. the attribute has been updated and the policy says so), store() in the registered persistent manager is called BUT with the ModelMbeanInfo metadata of the XMBean, not the call in progress.

Thus, store saves the PREVIOUS attribute cached value (if one exists, because it could even not be there, in case this attribute has never been get or set before).

Looking through the code, I can't find where the Attribute Descriptor is actually copied. All I see is object references being copied, not a new Descriptor being created, but apparently it must happen somewhere.

Any suggestions welcome,

Thanks
/Dimitris

[dimitris]

I was trying to verify the odd persistent behaviour. At some point I thought I was crazy because changes through the JMX console were persisted correctly. However, this is due to how the jmx-console is coded.

The scenario that proves the problem is the following:

1) Start your persistency-enabled XMBean without setting any attributes in the mbean descriptor
2) Point the console to the XMBean - the attribute(s) will be shown.
3) Touch the mbean descriptor so that the XMBean is re-deployed
4) Now change all attributes in the console (but do not refresh!) and press Apply Changes. The last attribute will not be saved (or if you have just one attribute nothing will be saved). Any attribute that is saved is because a subsequent set caused a previously set attribute to be saved. Obviously the last attribute will only be saved with the next update.

Cheers
/Dimitris

[ivelin.ivanov]

Posting a note from Scott Stark:

There is a org.jboss.test.jmx.test.DeployXMBeanUnitTestCase suite that has tests for persistence of xmbean attributes across redeployment. Can you add another test to this which illustrates the problem described here. How does this differ from the existing testUserXMBeanPersistentValues unit test in this case which deploys, sets a value, undeploys and then tests that the persisted value is seen?