As far as I can tell this is the same message you sent a few days ago. You
can find my response to that message here [1].


Justin

[1] https://lists.apache.org/thread/p2lxw22nhwhq015lvjn0kqtxdsdj3vx4

On Tue, Jan 3, 2023 at 7:13 PM John Lilley
<john.lil...@redpointglobal.com.invalid> wrote:

> Greetings!
>
>
>
> In our app, we have a lot of batch “jobs”, each of which stands up an RPC
> service on a unique queue.  However, when jobs quit, clients may still try
> to communicate and I don’t want this to hang, I want clients to see an
> error reply.  To this end, I am implementing a “fallback” service for
> ended-job RPC queues, of which there can be 100s,  that returns errors.
> This is expected to be very low traffic and the polling can be done
> infrequently (like every few seconds), so performance doesn’t matter.
>
>
>
> The queues are set to auto-delete, and in order to keep broker memory
> down, I don’t want to do anything to prevent auto-deletion.  Because in
> most cases, nothing will be posted to these queues.  I want to use a
> strategy like this:
>
> •             Enumerate queues first, to see which ones exist.
>
> •             Of the queues that exist, use the queue-based management API
> to get a message count (see method below).
>
> •             Only for queues that have a non-zero message count, create a
> consumer and call receive() to poll for messages.
>
>
>
> Will this strategy avoid interfering with the broker’s auto-delete?
>
> Is queue enumeration low-impact enough to call it every few seconds?
>
>
>
> Method used for getting queue count (this is all using the
> artemis-jms-client-all JMS client):
>
>
>
> public int getQueueEntryCount(String queueName) {
>
>   return getIntAttribute(queueName, "MessageCount");
>
> }
>
>
>
> private int getIntAttribute(final String queueName, final String
> attributeName) {
>
>   String resourceName = ResourceNames.QUEUE + queueName;
>
>   synchronized (lock) {
>
>     ClientRequestor client = getClient();
>
>     try {
>
>       ClientMessage request = clientSession.createMessage(false);
>
>       ManagementHelper.putAttribute(request, resourceName, attributeName);
>
>       ClientMessage reply = client.request(request);
>
>       if (ManagementHelper.hasOperationSucceeded(reply)) {
>
>         return (int)(long)ManagementHelper.getResult(reply, Long.class);
>
>       } else {
>
>         // Because we cannot tell the difference between
> queue-does-not-exist and a real error
>
>         return 0;
>
>       }
>
>     }
>
>     catch (Exception e) {
>
>       throw new RuntimeException("Error fetching " + attributeName + " for
> queue " + queueName, e);
>
>     }
>
>   }
>
> }
>
>
>
> Thanks
>
> John
>
>
>
> [image: rg] <https://www.redpointglobal.com/>
>
> John Lilley
>
> Data Management Chief Architect, Redpoint Global Inc.
>
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
>
> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com
>
> PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is
> confidential and is intended solely for the use of the individual(s) to
> whom it is addressed. If you believe you received this e-mail in error,
> please notify the sender immediately, delete the e-mail from your computer
> and do not copy, print or disclose it to anyone else. If you properly
> received this e-mail as a customer, partner or vendor of Redpoint, you
> should maintain its contents in confidence subject to the terms and
> conditions of your agreement(s) with Redpoint.
>

Reply via email to