Synchronizing Exchange WebService Managed API method calls

Question

I have written a listener class which creates an HTTP listener and subscribes its URL to push subscriptions (on new mail event on Inbox using EWS Managed API), receives notifications, processes mails and then move those mails to Deleted Items folder. I have also written a poller which periodically checks for any mails left out inside the inbox, processes them and then moves them to the Deleted Items folder. Listener and poller run in different threads.

I have synchronized these threads using locks. And the lock functionality is tested to work fine. However due to locking I am getting some undesired behavior.

Consider listener receives a push notification. It starts processing it. Meantime, poller starts and it acquires the lock. Now when listener tries to acquire the lock it finds that the lock is already acquired by the poller. So it waits till lock gets freed. Say listener executes till instruction INSTR-1 and continue waiting. Now poller is processing all mails in inbox for say 3-5 minutes. After that, poller releases the lock. In those 3-5 minutes, exchange continues to dispatch push notifications, however since first listener thread is stuck at INSTR-1 no more listener threads are dispatched by .NET runtime. But as soon as poller releases lock, all threads gets dispatched. But since their corresponding mails have been already processed and moved to Deleted Items folder by the poller, those listener threads throws the exception “The specified object was not found in the store.” on EmailMessage.Bind() method. Since I have now well analyzed this behavior and I know exactly why this exception is occuring, I can simply go on to suppress these exceptions (say with empty catch blocks).

However I will like to know,

1. if there is any way by which I can make Exchange Server to not to dispatch any push notifications after poller starts or in other words for those mails which have been already retrieved by EWS Managed API call ExchangeService.FindItems() made by poller.

2. if there is any standard / Microsoft recommended way to handle such problems

We can visualize the listener and poller procedures and execution behavior as follows:

Answer 1

To answer #1, the short answer is NO. There is no PAUSE functionality for receiving Push Notifications. You can't even Unsubscribe temporarily because there is no Unsubscribe for Push. (Not that you would want to in all likelihood.)

To answer #2, it would be pretentious of me to speak for MS, but all I've read suggests you should be doing the minimal amounts of work in your listener and poller. All these threads should be doing is getting the ItemId involved in the notification or email you're interested in, and queuing that up for further processing (Get, Move, Delete, etc.) Holding a lock for 3-5 minutes in general is not a good practice. (Locks should be held for milliseconds, if possible.) If you queue the ItemIds and have a separate thread (or threads) to process them outside of the poller/listener, that would be a more robust solution, IMHO.