After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784058 - Ignores Exchange backoff response
Ignores Exchange backoff response
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Miscellaneous / EWS Core
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-06-21 19:24 UTC by Martin Kelly
Modified: 2017-07-10 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
error message (891 bytes, application/xml)
2017-06-21 19:24 UTC, Martin Kelly
  Details
proposed patch (4.62 KB, patch)
2017-06-30 10:29 UTC, Milan Crha
committed Details | Review

Description Martin Kelly 2017-06-21 19:24:21 UTC
Created attachment 354196 [details]
error message

I'm using the EWS plugin and have noticed that, when syncing a
large amount of mail, it seems like the EWS plugin does not respond to
Exchange throttling messages. Specifically, I'm getting messages back
from the server with code ErrorServerBusy and a BackOffMilliseconds
value set. However, it seems like EWS is failing the transaction rather
than backing off. Note that I haven't done much code inspection (just
observed behavior and grepped for the string "BackOffMilliseconds" in
the sources), so I could be mistaken.

Here's more information about EWS throttling:
https://msdn.microsoft.com/en-us/library/office/jj945066(v=exchg.150).a
spx

I've attached the error sent from the server (seen by setting EWS_DEBUG=2).

Note that I'm using the Evolution debian package, version 3.22.6-1.
Comment 1 Milan Crha 2017-06-22 07:57:48 UTC
Thanks for a bug report.

> <t:Value Name="BackOffMilliseconds">149545</t:Value>

I'm wondering what evolution-ews should do in such cases. Getting this information to UI would not be the best thing, but seeing that the server says to wait for almost two and a half minute it would be pretty confusing for users to not see any update for that long without any indication what there's going on in the background.
Comment 2 Milan Crha 2017-06-30 10:29:07 UTC
Created attachment 354725 [details] [review]
proposed patch

Could I ask you to give a try to this patch for evolution-ews, supposing you are able to reproduce it, please? I tried to create this semi-blindly, by cheating what the server returned (replacing actual server response with the XML you attached), but having real server communication for testing would help a lot.

With respect of the UI feedback of the waiting, as long as the operation had been started with an activity, where most of the operations initiated are (the only exception I know of is the initial opening after start), then the countdown is shown in the status bar, with one second precision. It doesn't matter if other operations are piled meanwhile, they are just waiting too. These can be also cancelled, if needed.
Comment 3 Martin Kelly 2017-07-05 17:42:44 UTC
Thanks, I'll try it when I get a chance. I'm not sure yet whether or not I can repro but I'll try.
Comment 4 Milan Crha 2017-07-10 12:33:53 UTC
Thanks. Considering there's a release next week and that the change is harmless when no such response is received and that I tested it with some fake responses I'd just include it for the next release and eventually update it in case you find any downsides of the change in the real environment.

Created commit a05d03d in ews master (3.25.4+)
Created commit 6e6eb8c in ews gnome-3-24 (3.24.4+)