Ted Ross wrote:
My two cents...
I think this is an administrative function that is performed on-demand
and has no lasting affect on the normal operation of the broker (i.e. no
filters or redirects are used). I also think that this feature will be
used primarily as a diagnostic tool.
Since messages are not modeled as management objects, this feature must
be coupled with a message-query feature. A management method (or set of
methods) can be implemented on queue objects to allow management users
to get information about the set of messages on a queue.
[...]
This query feature can be used to provide visibility into the content of
a blocked or slow-moving queue.
In 0-10 you can already 'browse' the messages on a queue using the
not-acquired mode on your subscription. That could be a good way to
address this feature.
Though not yet implemented in the c++ broker, the arguments to subscribe
can be used to specify a selector (which is what we want for JMS support
anyway) that restricts the messages actually delivered for that
subscription.
A non-acquired message can be removed from the queue by acquiring it
(and acknowledging if required).
We could even add an option to the arguments for subscribe for
indicating that only the headers should be delivered for that
subscription if needed to reduce the amount of data that needed to be
transfered (would perhaps only be valid in not-acquired mode).
[...]
Note that message query and message move/copy will probably require that
the queue be locked during the duration of the operation so these may be
expensive features. It would be good to find a way to implement these
on a flowing queue without locking.
Browsing and acquiring as described above will already implement any
necessary locking.
