Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Office 365 EWS calendar access giving ErrorTooManyObjectsOpened

We are using the Exchange Web Service (EWS) API against Office 365 to create calendar events in the calendar of a user. This works fine for an on-premise deployment, but with an Office 365 deployment we seem to be hitting a throttling limit fairly quickly.

After creating 16 events, in the calendar of 16 different users (from a service account, using delegate access to the calendars), we receive the following error:

ErrorTooManyObjectsOpened - Too many concurrent connections opened

After ~5 minutes, this error clears and we can continue creating events. It seems that the EWS server caches connections to mailboxes, and Office 365 only seems to allow a connection to 16 mailboxes at a time.

We tried a lot to overcome this error, but have not found a 'final' solution or workaround. What we tried:

  • Using impersonation instead of delegation: this works, but is a no-go from a security perspective.
  • Using multiple service accounts: this works, although each account it still limited to ~16 users per 5 minutes.
  • We tried the X-AnchorMailbox and X-PreferServerAffinity headers, and we making requests with and without HTTP keep alive, and with and without keeping the HTTP cookies.This does not make any difference. From the debug info we see that we usually end up on the same front-end and back-end server if we keep the cookies/connection, and that we end up on a different front-end if we drop the cookies but send a X-AnchorMailbox header.
  • We have not yet tried the REST API, since the client credential flow is not available yet.

Only the CreateItems call seem to cause this problem, we can do a FindItems for many users without hitting a limit.

Is anyone aware of a way to overcome this limitation, e.g., is there some call we can do to close the cached mailbox sessions on the Office 365 side? Or is there an Office 365 administrator in the room who can shed some light on the exact throttling limits, and why they are so much lower than the on-premise Exchange throttling limits?

Other details: we are using a modified version of the EWS Java API, but have done some extensive research and are quite sure this problem is server-side.

like image 532
MikeN Avatar asked Jan 07 '15 12:01

MikeN


1 Answers

Unfortunately there is no call you can make to close the connections. Impersonation is the recommended solution. You said it's a "no-go" from a security perspective, can you elaborate?

like image 88
Jason Johnston Avatar answered Oct 19 '22 20:10

Jason Johnston