Note that there are some explanatory texts on larger screens.

plurals
  1. POMSMQ Peek Permissions Only (i.e. without Receive Permissions)?
    primarykey
    data
    text
    <p><strong>Summary (tl;dr):</strong> We're trying to set up a queue with <code>Peek</code> access but not <code>Receive</code> access for testing purposes (so a <code>Receive</code> request will fail but a <code>Peek</code> will succeed), but it seems MSFT has made that more difficult than anticipated.</p> <p><strong>Background:</strong> We have a local private MSMQ queue from which one process receives and processes (/consumes) messages. In some situations the processing can't be completed and the message stays in the queue (e.g. forwarding destination temporarily offline). A monitor was therefore added to peek at the queue every ~10 minutes and see if the message at the top is the same or not - if the consumer is stalled (the same message is at the top), the monitor triggers an alarm to indicate that something's wrong.</p> <p>To force the queues to stall for testing purposes (to make sure the monitor function works), we thought we'd just remove (but not <em>deny</em>) <code>Receive</code> permissions from the queue itself but still <em>allow</em> <code>Peek</code> (restarting MSMQ and everything to enforce new permissions), which would ideally allow the monitor to <code>Peek</code> the messages without allowing anyone to <code>Receive</code> (/remove) the messages, 'stalling' the queue and generating an alarm.</p> <p>While testing this scenario out, however, I ran into an exception that seems to foil this approach:</p> <pre><code>System.Messaging.MessageQueueException: Access to Message Queuing system is denied. at System.Messaging.MessageQueue.MQCacheableInfo.get_ReadHandle() at System.Messaging.MessageQueue.StaleSafeReceiveMessage(UInt32 timeout, Int32 action, MQPROPS properties, NativeOverlapped* overlapped, ReceiveCallback receiveCallback, CursorHandle cursorHandle, IntPtr transaction) at System.Messaging.MessageQueue.ReceiveCurrent(TimeSpan timeout, Int32 action, CursorHandle cursor, MessagePropertyFilter filter, MessageQueueTransaction internalTransaction, MessageQueueTransactionType transactionType) at System.Messaging.MessageQueue.Peek(TimeSpan timeout) </code></pre> <p>This indicates (to me at least) that <code>Peek()</code> internally calls <code>ReceiveCurrent()</code> and must try a transactional <code>Receive</code> that it will then roll back /abort after it's done getting the message. Firing up .NET Reflector, I found that all instances of <code>Peek</code> call some variant of <code>Receive</code>, so a different <code>Peek</code> won't help. So it seems like <code>Receive</code> permissions are <em>required</em> in order to <code>Peek</code> as well, which seems kind of dumb as far as queue design goes.</p> <p>Note that both the consumer and monitor use the same account (/permissions) and changing the monitoring <em>method</em> (using <code>Peek</code>) isn't a viable option at this point (as that would require significant changes to requirements, specifications, and production code that would cost more than its worth) (though I guess you could propose monitoring methodology changes anyways if you really have to as they might be useful to others if they run into the same thing).</p> <p><strong>Finally, the Question:</strong> Is there a better (or even just different :p) way to <code>Peek</code> at the top of the queue without needing <code>Receive</code> permissions? Or a different way to set the permissions (via permissions interface, via code, etc.) such that <code>Receive</code> itself fails but <code>ReceiveCurrent</code> and other methods required to <code>Peek</code> work?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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