GNOME Bugzilla – Bug 689382
ResolveNames requests which return no results aren't cached (optimalisation)
Last modified: 2013-04-23 07:49:11 UTC
Hi, I'm working at a large company where a lot of people only work for a short time (like several months) after which they start working for other companies. This causes quite a lot of user account changes on our Exchange environment. User accounts frequently get added or deleted. While using evolution-ews to open my Exchange mailbox I noticed something odd. Initially evolution-ews tries to read the contents of a mail folder. Once it knows which mails are in a folder then it tries to retrieve additional information about all the e-mail addresses which are mentioned in these mails. The Exchange API function ResolveNames is used to retrieve this information. In the evolution-ews account configuration I've enabled the option to cache the contents of the Global Address List. When EWS_DEBUG=2 is set then a huge amount of ResolveNames calls can be observed for large mail boxes (my mailbox for example is more than 3 years old and contains thousands of mails). When looking more closely at the output I noticed that a large amount of these ResolveNames API calls return 'No results were found.' messages to requests where the user account in question doesn't exist on the Exchange server any more. This looks to me like correct behavior. For the situation where the ResolveNames API function returns no results evolution-ews doesn't seem to do anything with this information. -- Here's an example describing the situation: Initially the Exchange server contains the following user accounts: - user1@domain - user2@domain - myaccount@domain The account 'myaccount@domain' has the following mails in one of his mail folders: - e-mail 1 - from: user1@domain - subject foo - e-mail 2 - from: user2@domain - subject bar - e-mail 3 - from: user1@domain - cc: user2@domain - subject baz - e-mail 4 - from: user1@domain - subject xyz Now the account 'user1@domain' gets removed from the Exchange server. After the account 'user1@domain' is removed from the server evolution-ews is used to open the mail folder of 'myaccount@domain' Based on the EWS_DEBUG logs it looks like evolution-ews currently does the following for this situation: - Retrieve additional info about e-mail 1 - Check the local cache to find out if the details for 'user1@domain' are already known - Details of 'user1@domain' aren't in the cache yet - Perform ResolveNames API call to look up details for 'user1@domain' - Server returns 'no results found' as the account doesn't exist on the server any more - Retrieve additional info about e-mail 2 - Check the local cache to find out if the details for 'user2@domain' are already known - Details of 'user2@domain' aren't in the cache yet - Perform ResolveNames API call to look up details for 'user2@domain' - Server returns one result - Result is saved in local cache - Retrieve additional info about e-mail 3 - Check the local cache to find out if the details for 'user1@domain' are already known - Details for 'user1@domain' aren't in the cache yet - Perform ResolveNames API call to look up details for 'user1@domain' (== again ==) - Server returns 'no results found' as the account doesn't exist on the server any more - Check the local cache to find out if the details for 'user2@domain' are already known - Details for 'user2@domain' are found in the local cache, no need to ask the Exchange server - Retrieve additional info about e-mail 4 - Check the local cache to find out if the details for 'user1@domain' are already known - Details for 'user1@domain' aren't in the cache yet - Perform ResolveNames API call to look up details for 'user1@domain' (== again ==) - Server returns 'no results found' as the account doesn't exist on the server any more -- In the example mentioned above evolution-ews sends 3 ResolveNames requests to the Exchange server which all ask for more details about the 'user1@domain' account. For these 3 requests the server returns 'no results found' as the account doesn't exist on the server any more. To avoid sending too many duplicate/unnecessary requests to the Exchange server evolution-ews should perform the ResolveNames request for each discovered e-mail address only once and when this call returns no results evolution-ews should remember this fact so it doesn't have to ask the server again.
*** This bug has been marked as a duplicate of bug 686227 ***
Hi David, I'm afraid this bug isn't resolved yet. I was already using git master (0756a0) which includes the commit from bug 686227. After updating to git master yesterday I made sure that all evolution-related processes were killed before restarting evolution (that is evolution-source-registy, evolution-alarm-notify, evolution-calender-factory and evolution itself). I updated to git master to find out whether another evolution-ews bug I reported (bug 685795) is resolved now (which indeed is the case) so I'm pretty sure the latest git master is indeed used. I took a quick look at commit http://git.gnome.org/browse/evolution-ews/commit/?id=39da2c5742458c75aebd9831dc5b9a3ac0b9c5a5 and I think the caching pieces are only implemented in the add_item_to_cache function in the file src/calendar/e-cal-backend-ews.c (but I may be wrong here as I'm not that familiar yet with the evolution-ews code). This bugreport is about the mail component, not the calender component. Perhaps a similar caching mechanism also needs to be implemented in the mail component?
I introduced this in bug #679305, I didn't get that the EWS may return EX addresses only for people not in the directory any more, but it makes sense. I asked Mikhail to verify, and if he'll confirm, then I'll remove this code from evo-ews. Let's deal with this issue together with the calendar part, just to make things easier for me. I'll update the other bug as well. *** This bug has been marked as a duplicate of bug 686227 ***