Qpid
  1. Qpid
  2. QPID-1574 QMan WS-DM Adapter
  3. QPID-1578

Set termination time (and therefore destroy them) on WS-resources when the corresponding Qpid object instance is removed.

    Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.5
    • Component/s: None
    • Labels:
    • Environment:

      J2SE 1.5 or higher

      Description

      When an obejct instance is removed on Qpid side (expired session, deleted queue, etc), QMan receives a content indication message which contains the expiration date for that object.

      After that, the JMX core detects the corresponding MBean and unregister that from the MBeanServer. What needs to be done is, as conseguence of that event, to inform the WS-DM Adapter in order to let it set the termination time (and destroy) the corresponding WS-Resource.

        Activity

        Andrea Gazzarini created issue -
        Andrea Gazzarini made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        Andrea Gazzarini logged work - 17/Jan/09 06:57
        • Time Spent:
          48h
           
          <No comment>
        Hide
        Andrea Gazzarini added a comment -

        Feature has been introduced with commit(s) that you can see in the apposite section.
        The following is a brief riepilogue Lifecycle of QMan resource (let's suppose for simplicity that only one managed resource, a queue, exists on Qpid) :

        • Qpid starts;
        • QMan starts;
        • A content indication message is sent to QMan. This message referes to a queue instance.
        • Message is received by QMan but it doesn't know what is a "queue", its definition so therefore the incoming data is stored in raw (byte []) format and a schema request is sent to Qpid for "queue" class.
        • Qpid receives the schema requests and produces the corresponding schema response;
        • QMan receives the schema response, builds the queue class definition, uses the previously stored raw data for create and populate the MBean instance corresponding to queue object. A JMX Notification is sent to all registered listeners.
        • The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the creation of the queue instance.
        • The incoming notification provides the objectname (the JMX identifier) of the created object so the WSDM adapter uses the MBEan Info in order to introspect the queue object instance and therefore create the WS-Resource including its WSDL and capability class.

        Now the queue exists under the following perspectives :

        • on Qpid broker as a manageable object instance;
        • on QMan JMX core as an MBean
        • on QMan WS-DM as a WS-Resource (WSDL + capability classses)

        Let's suppose that, for some reason, the queue is deleted (undeclared) from Qpid. What is happening on QMan side? Here it is :

        • A content indication message is sent by the broker to QMan with a "timeObjectWasDeleted" property valorized with the corresponding value;
        • QMan detects that the instance has been removed and as a conseguence of that the corresponding MBean is unregistered from MBean Server; A JMX notification is sent to all registered listeners.
        • The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the deletion of the queue instance.
        • The incoming notification provides the objectname of the mbean that has been removed. The WS-DM Adapter, which is using that objectname as resource identifier, uses that for find the WS-Resource and destroy it.

        At this point the queue resource has been deleted from all the perspective.

        Regards,
        Andrea

        Show
        Andrea Gazzarini added a comment - Feature has been introduced with commit(s) that you can see in the apposite section. The following is a brief riepilogue Lifecycle of QMan resource (let's suppose for simplicity that only one managed resource, a queue, exists on Qpid) : Qpid starts; QMan starts; A content indication message is sent to QMan. This message referes to a queue instance. Message is received by QMan but it doesn't know what is a "queue", its definition so therefore the incoming data is stored in raw (byte []) format and a schema request is sent to Qpid for "queue" class. Qpid receives the schema requests and produces the corresponding schema response; QMan receives the schema response, builds the queue class definition, uses the previously stored raw data for create and populate the MBean instance corresponding to queue object. A JMX Notification is sent to all registered listeners. The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the creation of the queue instance. The incoming notification provides the objectname (the JMX identifier) of the created object so the WSDM adapter uses the MBEan Info in order to introspect the queue object instance and therefore create the WS-Resource including its WSDL and capability class. Now the queue exists under the following perspectives : on Qpid broker as a manageable object instance; on QMan JMX core as an MBean on QMan WS-DM as a WS-Resource (WSDL + capability classses) Let's suppose that, for some reason, the queue is deleted (undeclared) from Qpid. What is happening on QMan side? Here it is : A content indication message is sent by the broker to QMan with a "timeObjectWasDeleted" property valorized with the corresponding value; QMan detects that the instance has been removed and as a conseguence of that the corresponding MBean is unregistered from MBean Server; A JMX notification is sent to all registered listeners. The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the deletion of the queue instance. The incoming notification provides the objectname of the mbean that has been removed. The WS-DM Adapter, which is using that objectname as resource identifier, uses that for find the WS-Resource and destroy it. At this point the queue resource has been deleted from all the perspective. Regards, Andrea
        Andrea Gazzarini made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Andrea Gazzarini made changes -
        Time Spent 48h [ 172800 ]
        Remaining Estimate 48h [ 172800 ] 0h [ 0 ]
        Robbie Gemmell made changes -
        Labels qman
        Robbie Gemmell made changes -
        Component/s Java Management : QMan [ 12312540 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        20h 22m 1 Andrea Gazzarini 16/Jan/09 07:50
        In Progress In Progress Resolved Resolved
        2d 23h 1 Andrea Gazzarini 19/Jan/09 06:51

          People

          • Assignee:
            Andrea Gazzarini
            Reporter:
            Andrea Gazzarini
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 48h
              48h
              Remaining:
              Remaining Estimate - 0h
              0h
              Logged:
              Time Spent - 48h
              48h

                Development