Databases
StackOverflow2013
Postsdbo
POIBM-MQ reader in .net XMS to ack processed messages one-by-one
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POIBM-MQ reader in .net XMS to ack processed messages one-by-one
    primarykey
    data
    text
    <p>I am implementing a component that reads all the messages off a specific queue as they are available but should only remove messages from the queue asynchronously, after the message contents has been processed and persisted. We read messages off faster than we acknowledge them (e.g. we could read have read 10 messages off before we are ready to Ack the first). The current implementation uses the XMS API, but we can switch to MQI if XMS is inappropriate for these purposes.</p> <p>We have tried two approaches to try solve this problem, but both have drawbacks that make them unacceptable. I was hoping that someone could suggest a better way.</p> <p>The first implementation uses an <code>IMessageConsumer</code> in a dedicated thread to read all messages and publish their content as they are available. When the message has been processed, the <code>message.Acknowledge()</code> method is called. The Session is created with <code>AcknowledgeMode.ClientAcknowledge</code>. The problem with this approach is that, as per the documentation, this acknowledges (and deletes) ALL unacknowledged messages that have been received. With the example above, that would mean that all 10 read messages would be acked with the first call. So this does not really solve the problem. Because of the reading throughput we need, we cannot really modify this solution to wait for the first message's ack before reading the second, etc.</p> <p>The second implementation uses an <code>IQueueBrowser</code> in a decided thread to read all messages and publish their content. This does not delete the messages off the queue as it reads. A separate dedicated thread then waits (on a BlockingQueue) for JMS Message IDs of messages that have been processed. For each of these, it then constructs a dedicated <code>IMessageConsumer</code> (using a message selector with JMSMessageID) to read off the message and ack it. (This pairing of an <code>IQueueBrowser</code> with dedicated <code>IMessageConsumer</code> is recommend by the XMS documentation's section on <b>Queue browsers</b>.) This method does work as expected but, as one would imagine, it is too CPU-intensive on the MQ Server.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJosh
    1. USJosh
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POIBM-MQ reader in .net XMS to ack processed messages one-by-one
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYes, that's the behavior, messages can't be acknowledged random. One message acknowledge will ack all earlier messages. There is no option in MQ .NET either. From your description it appears that you are OK with acknowledging all messages with one ack call but you more concerned about throughput. What throughput are you expecting?
      singulars
      1. POIBM-MQ reader in .net XMS to ack processed messages one-by-one
      1. USShashi
    2. COExpected throughput: Up to 1 million messages per day on the most active queue and 10 million messages per day for all queues on the MQ server combined.
      singulars
      1. POIBM-MQ reader in .net XMS to ack processed messages one-by-one
      1. USJosh
    3. COJust to clarify: the main reason that we can't really read and process each message sequentially (before reading off the next) is that the actual processing has a fairly significant lead time - that's why we need to have many messages being processed simultaneously.
      singulars
      1. POIBM-MQ reader in .net XMS to ack processed messages one-by-one
      1. USJosh
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload