qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: Admin: Moving messages from one queue to another.
Date Tue, 05 Aug 2008 12:17:41 GMT
2008/7/30 Gordon Sim <gsim@redhat.com>:
> 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.

I agree with Ted that these are one off actions on a queue rather than
predefined filters. e.g. A client is unable to process the message at
the front of the queue. Move this message to another queue so it can
be manually inspected and potentially returned to the former queue.

That said we are in the process of adding Binding level filters to the
Java broker so that we can correctly apply selectors on JMS Topics,
other filters should not be difficult to apply after that.

Martin Ritchie

View raw message