none
Preventing RopBackoff RRS feed

  • Question

  • I've written a service style app that logs on to multiple mailboxes through a single connection.  The app first syncs the folder hierarchy (via the sync ROPs), then syncs the messages in the folders for each of the connected users.  Functionally it works fine.  To improve performance, I made the app multi-threaded.  With a low processing thread count (1-3) everything is fine.  Above that, I start to get RopBackoffs every once in a while, typically grouped together in batches.

    I understand that there will be times where the Exchange server will be unable to process my request and will need me to wait.  I don't understand why Exchange just doesn't wait internally and complete the operation when it can.  Since it doesn't work that way, what are the circumstances that Exchange will send back a RopBackoff?  Is it CPU/memory/IO based?  Are there any guidelines for preventing a RopBackoff, or is it just a normal part of the protocol that I have to deal with?  The other size effect I'm seeing is that if Exchange sends a RopBackoff more than once for the request, the next response is an Access Denied.

    The documentation is a little thin on RopBackoff, so any help would be appreciated.
    Joe

    Tuesday, May 5, 2009 3:30 PM

Answers

  • There is no clear cut answer as this is determined by client load, types of ROP requests, outstanding asynchronous ROP requests, physical resources (CPU/IO/memory) that effect how fast Exchange can process ROP requests.  A client for example can make an asynchronous RPC call and/or flag a specific ROP to be asynchronous so the protocol has built in support for telling a client to back off.  

    As you pointed out RopBackoff does not have a lot of information outside of what is documented in [MS-OXCROPS].  I will ask development to see if there is a home for additional details that could be added to the Exchange protocol specification.

    Thank you for your feedback.


    Developer Consultant
    • Marked as answer by JoeDoyle23 Wednesday, May 6, 2009 8:22 PM
    Tuesday, May 5, 2009 7:45 PM
    Moderator

All replies

  • There is no clear cut answer as this is determined by client load, types of ROP requests, outstanding asynchronous ROP requests, physical resources (CPU/IO/memory) that effect how fast Exchange can process ROP requests.  A client for example can make an asynchronous RPC call and/or flag a specific ROP to be asynchronous so the protocol has built in support for telling a client to back off.  

    As you pointed out RopBackoff does not have a lot of information outside of what is documented in [MS-OXCROPS].  I will ask development to see if there is a home for additional details that could be added to the Exchange protocol specification.

    Thank you for your feedback.


    Developer Consultant
    • Marked as answer by JoeDoyle23 Wednesday, May 6, 2009 8:22 PM
    Tuesday, May 5, 2009 7:45 PM
    Moderator
  • Yes you can receive mutiple RopBackoff in responses as the check is done before each ROP in the request.  

    I'm assuming you are referring to the ReturnValue in the response buffer of returning AccessDenied, which is defined in [MS-OXCDATA],  means that you do not have sufficient access rights to perform the operation.  I would have to know more details about what you are doing to respond.


    Developer Consultant
    Tuesday, May 5, 2009 9:27 PM
    Moderator
  • Yes, the Access Denied is in the ReturnValue.  In the RopBackoff, I'm getting a BackoffRopCount of 0, which from the docs means the all Rops for the logon should pause.  Currently my code doesn't handle that correctly and while the thread that received the RopBackoff will puase for the duration specified before retrying, the other threads may still be sending requests in.  If too many of those requests hit the server, then I will eventually get an 80004005 in the ReturnValue for some of the requests.  The server then "catches up" and requests start getting completed again.

    The permissions are correct on the objects I'm accessing.  If I run with only a single thread, I get no RopBackoffs and no errors returned back.  I did some testing and I can typically ramp up to 3 threads before I start to see RopBackoffs.

    I'm ok with getting RopBackoffs.  I just wanted to make sure I understood the mechanics correctly so I know how to correct my code to properly handle them.  Your first response confirms my thoughts that these are sent when the Exchange server has other things going on, without a specific reason.  The Exchange server I'm testing against is just a dev box and is no where near production specs, so I expect it not to be as performant.

    I'll be on the look out for any updates in 2.1, otherwise I think I have the answers I need.

    Thanks,
    Joe


    Tuesday, May 5, 2009 10:01 PM
  • Make sure you set your client version to be at least 12.0.4228.0 when you call EcDoConnectEx as spelled out here in section shown below.

    <snippet specification="[MS-OXCROPS]">
    3.1.5.1.1  RopBackoff

    Any client reporting its version as 12.0.4228.0 or later (as specified in [MS-OXCRPC]) MUST support processing the RopBackoff response buffer. The layout of this ROP is specified in section 2.2.14.2.
     
    RopBackoff can appear at any location in the ROP output buffer. This ROP response indicates that the server requests the client delay the resending of ROP requests for the specified logon or type of ROPs for an amount of time. When this response contains a non-zero RopIdBackoff, it specifies the ROP request that needs to be delayed. The ROP response that was delayed and all subsequent ROP responses will not be in the buffer. When the BackoffRopCount is set to 0x00, this indicates that all ROP requests for that logon are to be delayed.
    </snippet>

    Developer Consultant
    Wednesday, May 6, 2009 8:19 PM
    Moderator