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 656709 - Excessive updates being sent to server.
Excessive updates being sent to server.
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Mail
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-08-17 00:09 UTC by David Woodhouse
Modified: 2012-07-19 09:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
ews patch (6.75 KB, patch)
2012-07-19 09:39 UTC, Milan Crha 		committed Details | Review

Description David Woodhouse 2011-08-17 00:09:51 UTC 
We seem to be sending *loads* of "updates" to the server which look like this:
    <ItemChange>
     <ItemId Id="AAMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwBGAAAAAAALWV8jNZpCRJWux9Gj6imzBwAxUrM3tYzfT6fnccKZasBfAAAALPtvAACnCUASyhvDT7JwON9NYNl4AAAAAUd9AAA=" ChangeKey="CQAAABYAAACnCUASyhvDT7JwON9NYNl4AAAABlbo"/>
     <Updates>
      <SetItemField>
       <FieldURI FieldURI="item:Categories"/>
       <Message>
        <Categories/>
       </Message>
      </SetItemField>
     </Updates>
    </ItemChange>

This will be because of the 'OK, the change must have been the labels' bit in ews_synchronize_sync(). It's wrong to assume that. We should only include messages in our list if we really *are* going to send an update for them.
Comment 1 shiran.stan-meleh 2011-08-24 12:05:33 UTC 
HI,

Can you tell what kind of request was it or send a full
request log?

Thanks,
Comment 2 David Woodhouse 2011-08-24 15:21:30 UTC 
It has to have been an UpdateItem request, surely? Where else would we create a request like the above? I even pointed you at the part of the code which causes it...
Comment 3 shiran.stan-meleh 2011-08-25 07:33:18 UTC 
Was looking in the wrong place.
Found it under msg_update_flags() and already have a fix pending
Comment 4 Milan Crha 2012-07-19 09:25:29 UTC 
Downstream bug report about the same from 3.4.3:
https://bugzilla.redhat.com/show_bug.cgi?id=841443

User claims that after initial folder fetch there is huge CPU usage. I realized that it can be also caused by this bug, thus I looked deeply into it.
Comment 5 Milan Crha 2012-07-19 09:39:37 UTC 
Created attachment 219214 [details] [review]
ews patch

for evolution-ews;

With this patch the initial folder download does not leave message infos with CAMEL_MESSAGE_FOLDER_FLAGGED, thus on folder store these are not evaluated as being changed locally, and no upload of items is done. I also fixed ews_synchronize_sync() to not check CamelMessageInfo::dirty property, because it's there only for folder summary, indication of changes in message info itself is done only by the CAMEL_MESSAGE_FOLDER_FLAGGED flag.
Comment 6 Milan Crha 2012-07-19 09:43:58 UTC 
Created commit 2122dc8 in ews master (3.5.5+)
Created commit f91e481 in ews gnome-3-4 (3.4.4+)