none
Deleted Item not actually getting deleted or **delay** deleted thus getting refetched (EWS Managed API) RRS feed

  • Question

  • I am polling Exchange Server to fetch all the mails left in the Inbox and then fetching them, processing them and finally moving them to the deleted folder. My procedure takes following form of EWS Managed API calls:

    1    itemResults = service.FindItems(WellKnownFolderName.Inbox, itemView);
    2    //some code...
    3    service.LoadPropertiesForItems(itemResults.Items, itItemPropSet);
    4    //some code...
    5    foreach(Item item in itemResults) 
    6    {
    7       //process item 
    8       item.Delete(DeleteMode.MoveToDeletedItems);
    9    }

    To test this code I flooded the inbox with 5000 mails, 5 threads flooding 1000 mails each at the interval of 4ms.

    After test run, I realized some mails are getting processed multiple times.

    When I read the soap traces logged using TraceListener, I realized that when there are more than 100 mails in the inbox, there are more SOAP packets were dispatched in burst of 100s.

    Logically below set of SOAP Packets (let us call it "Set 1") should occur only once:

    <m:FindItem>...</m:FindItem> //generated by line 1
    <m:FindItemResponse>...</m:FindItemResponse> //generated by line 1
    <m:GetItem>...</m:GetItem> //generated by line 3
    <m:GetItemResponse>...</m:GetItemResponse> //generated by line 3

    followed x number of Delete SOAP packets for x number of mails in the Inbox

    <m:DeleteItem>...</m:DeleteItem>  //generated by line 8
    <m:DeleteItemRepsonse>...</m:DeleteItemRepsonse> //generated by line 8

    However if there are say 325 mails in the inbox, then there first occurs 4 occurences of Set 1 followed by Delete SOAP packest as follows:

    //1st occurence <m:FindItem>100 items</m:FindItem> <m:FindItemResponse>100 items</m:FindItemResponse> <m:GetItem>100 items</m:GetItem> <m:GetItemResponse>35 items</m:GetItemResponse> //2nd occurence <m:FindItem>100 items</m:FindItem> <m:FindItemResponse>100 items</m:FindItemResponse> <m:GetItem>100 items</m:GetItem> <m:GetItemResponse>35 items</m:GetItemResponse> //3rd occurence <m:FindItem>100 items</m:FindItem> <m:FindItemResponse>100 items</m:FindItemResponse> <m:GetItem>100 items</m:GetItem> <m:GetItemResponse>100 items</m:GetItemResponse> //4th occurence <m:FindItem>35 items</m:FindItem> <m:FindItemResponse>35 items</m:FindItemResponse> <m:GetItem>35 items</m:GetItem> <m:GetItemResponse>35 items</m:GetItemResponse>

    //****followed by 335 occurences of the Delete SOAP packets****

    <m:DeleteItem>...</m:DeleteItem>  
    <m:DeleteItemRepsonse>...</m:DeleteItemRepsonse> 
    //334 more of above

    So there are 100 + 100 + 100 + 35 = 335 items actually getting handled, which is 10 more than what are actually present in the inbox. 

    Also notice that Delete SOAP packets are queued till end. They are not dispatched in burst.

    1. First thing I realize dispatching SOAP packets in burst of 100s is EWS Managed API behavior. I guess there must be traffic reason behind it and there must be some configuration setting to tweak it. Q1. How can we change this count of 100?
    2. I inferred that there are some overlaps in fetching of mails.

    So I copy pasted SOAP Traces for first two of

    <m:GetItem>100 items</m:GetItem>

    in two different files, and compared them in text comparer. I realised that some mails that are at the end of the first 100s were reappearing at the beginning of 2nd 100: 


    This is the pattern in many test runs.

    Due to this these overlapping mails, these mails are getting processed twice. Also the attempt to second time delete them was throwing exception : The specified object was not found in the store.

    So I guess there is time delay in delete mail API call and mails actually getting deleted, between which they are getting refetched. Q2. How can I handle this to avoid redundant processing of mails and unnecessary exceptions.



    • Edited by Mahesha999 Wednesday, March 5, 2014 11:20 AM
    Tuesday, March 4, 2014 5:10 PM