-
1. Re: JMX persistence issues
dimitris Aug 16, 2004 7:03 PM (in response to ivelin.ivanov)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 -
2. Re: JMX persistence issues
dimitris Aug 17, 2004 8:29 PM (in response to ivelin.ivanov)
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 -
3. Re: JMX persistence issues
ivelin.ivanov Aug 25, 2004 2:54 PM (in response to 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?