[
https://issues.apache.org/jira/browse/QPID-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Gazzarini resolved QPID-1578.
------------------------------------
Resolution: Fixed
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
> Set termination time (and therefore destroy them) on WS-resources when the
> corresponding Qpid object instance is removed.
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-1578
> URL: https://issues.apache.org/jira/browse/QPID-1578
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Management : QMan
> Affects Versions: M5
> Environment: J2SE 1.5 or higher
> Reporter: Andrea Gazzarini
> Assignee: Andrea Gazzarini
> Fix For: M5
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
