Ticket #223 (closed Defect: Duplicate)
Directory cache miss not always working
|Reported by:||wsanchez@…||Owned by:||wsanchez@…|
10/1/07 7:51 AM Cyrus Daboo:
The directory cache miss feature does not always work.
- STEPS TO REPRODUCE
- Start calendar server with at least one existing user account.
- Configure a new user account on the server via WGM.
- In iCal create an account for the initial user.
- Try to add the new user as a delegate.
2007-10-01 11:44:44-0400 [-] [caldav-8009] [AMP,client] PROPPATCH /principals/__uids__/BA301DC7-92FE-43A7-A7F3-C16B2D26A7FE/calendar-proxy-read/ HTTP/1.1 2007-10-01 11:44:44-0400 [-] [caldav-8009] [-] 'No principal found for UID: 8C6D1CA4-25C3-47F6-B907-C5B7192BB4F1'
After steps above, if you then create an account for the new user in iCal that works (i.e. cache miss occurs and the server provisions the account). After doing that it is possible to add the new user as a delegate of the existing one.
So in some cases the cache miss code is not being called when a principal-URI is not found. This leads to a poor user experience as users have to wait at most 30 mins for new user accounts to be provisioned in order to use them without the new user first having to create their account int he client.
10/3/07 6:57 PM Cyrus Daboo:
A similar problem exists when creating a new user and then attempting to immediately invite them. If the calendar server has not updated its cache yet, it cannot map the cu-address in the invite to the new user and thus it rejects the POST.
We need to have a cache miss operation for calendar user addresses too. i.e. if a calendar user address is not found we need to do a query for the cu-addr in the directory. The trouble is this depends on the form of the cu-addr. A mailto cu-addr can be queried directly ( we have to do that because the local part of the email address may not match the record name of the directory record for that email address). An http cu-addr has to be decomposed to get the record name/guid and then looked up.
10/26/07 8:53 AM Cyrus Daboo:
Also hitting /principals/uids/XXXX does not seem to trigger a cache miss for XXXX.