Re: Admin: Moving messages from one queue to another.

[Alan Conway <ac...@redhat.com>]

On Wed, 2008-07-30 at 10:49 +0100, Gordon Sim wrote:
> 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.

+1. I'd argue this should be done by an admin client rather than
complicating the broker unless there is a compelling use case that is
impossible to support without broker changes.