3 Replies Latest reply on Aug 25, 2004 2:54 PM by Ivelin Ivanov

    JMX persistence issues

    Ivelin Ivanov Expert

      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.

        • 1. Re: JMX persistence issues
          Dimitris Andreadis Master

          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 Andreadis Master


            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 Expert

              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?