Hi Rajesh,
I worked a lot on getting the .NET binding for C++ Messaging but have
not put effort into the QMF management interface.
Frase has a good suggestion in how to use address strings to get
what you want. Here are example commands for drain and spout:
> csharp.example.spout "my-queue; {create:receiver}"
> csharp.example.drain --timeout 5 "my-queue; {create:receiver,
> delete:receiver}"
The test scenario first runs spout, which fails because the queue does not
exist.
Then run drain and before the timeout expires run spout again. Spout succeeds
and drain receives the message. After the timeout expires then drain exits and
the queue is deleted in the broker. Running spout again will fail because the
queue does not exist.
Regards,
Chuck
----- Original Message -----
> From: "Fraser Adams" <[email protected]>
> To: [email protected]
> Sent: Thursday, February 14, 2013 1:38:33 PM
> Subject: Re: How to empty a queue programatically
>
> Hi Rajesh,
> I'm not sure that this is possible programatically in the way that
> you
> are suggesting - well short of receiving and discarding which I'm
> guessing you'd already thought of :-)
>
> It is definitely possible to do it programatically though using QMF
> (assuming that you are talking about using the C++ broker?). In QMF
> there is a purge method on the queue Management Object that allows
> you
> to remove a specified number of messages (zero for all messages).
>
> The down side is that it takes something of an up front effort to do
> things using QMF from a standing start, with C# it's probably even
> harder (I've done things with Java, Python, C++ and JavaScript).
>
> You can actually do this using the REST API that is the back end of
> my
> GUI (it's a POST method taking a JSON String with the QMF arguments)
> but
> it's some effort to do from a standing start.
>
> Have you thought about addressing your problem from a different
> direction. For example if the first thing that you want to do when
> you
> connect your receiver is to clear the queues I'm wondering why you
> need
> the queues in place at all when the receiver is not connected?
> Couldn't
> you set up your receiver's Address to declare a queue (create
> receive)
> and make it an exclusive auto delete queue. In other words create the
> receiver's queues when it connects and delete them when it
> disconnects.
>
> That'll have the same net effect as having clear queues when the
> receiver connects.
>
> I'm assuming of course that the queues in question are exclusive to
> the
> receiver in question, if you want to clear a queue shared with
> another
> receiver when a particular receiver connects then I think that QMF
> purge
> or receive/discard are your only two options.
>
> Unless anyone else has a brighter idea??
>
>
> I couldn't tell you how to do this in C# but I've attached an example
> in
> Java that uses my QMF2 API. It's called QueueFuse it was a little
> experiment whereby instead of using circular queues I intercepted the
> queueThresholdExceeded QMF Event and invoked purge to delete ~20% of
> the
> messages on the queue that triggered the Event.
>
> This application is bundled in the archive with the GUI and QMF2 API.
> Unfortunately as I say it's Java/REST/JavaScript centric but
> hopefully
> it might give you some ideas. The Console class has the code to show
> how
> to construct the Map message necessary to invoke a QMF method so if
> you're keen you could use that as a basis for constructing the same
> message in C#
>
> HTH
> Frase
>
>
>
> On 14/02/13 15:26, Rajesh Khan wrote:
> > I am currently designing a receiver in C# and I wanted to know if
> > there was
> > a way for me to clear the queues (all its items) as soon as I
> > connect to it
> > . Any suggestions in this regard would be appreciated.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
