On Mar 8, 2013, at 8:06 AM, Robert Bruce <rbruce@celsiusinc.com> wrote:

So is there any way to disable the caching?  I really need a working Calendar server...

Everything is working fine except having to do every operation twice to get it to stick...

Something is pretty broken here; it's completely abnormal to have to do things twice to get them to stick.

How can I debug this?  

We'll need a snapshot of client and server logs covering an example reproduction of the problem.

One easy way to collect iCal logs (without making any persistent changes to logging configuration) is to launch iCal using Terminal with some additional arguments.

1) In a Terminal window, run the following, which launches iCal and sends all debug output to the terminal window (this is for Snow client. For Mountain Lion, see this document):
/Applications/iCal.app/Contents/MacOS/iCal -LogHTTPActivity YES -iTIPLogDetailedActivity YES -CalDAVNotificationLog YES

2) Note the wall-clock time, then reproduce the problem (i.e. that you have to do things twice for them to stick).

3) Note the time again, then control-c the terminal window to kill iCal, and save the entire transcript as a text file.

4) Extract the relevant portions of the server's access.log and error.log, covering only the time during the problem reproduction please.

Finally, please reply (privately, as the logs contain some possibly sensitive info like email addresses, etc) with the above logs and we'll have a look!

Thx,
-dre


Thank you, 


On 2013-03-07, at 12:09 PM, Cyrus Daboo wrote:

Hi Robert,

--On March 7, 2013 at 12:04:56 PM -0500 Robert Bruce <rbruce@celsiusinc.com> wrote:

::ffff:192.168.1.38 - - [07/Mar/2013:12:03:02 -0400] "DELETE
/calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
cs HTTP/1.1" 412 157 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
(997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=12.7
::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:02 -0400] "GET
/calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
cs HTTP/1.1" 200 705 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
(997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=22.4




Second try delete works...



::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:51 -0400] "DELETE
/calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
cs HTTP/1.1" 204 0 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
(997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=511.1




The deletes that work are not followed by a GET...


OK, so the client is doing a conditional DELETE request - i.e. it is asking the server to only do the DELETE if the resource on the server is unchanged from the one that the client originally cached. For some reason it is not, so a 412 error comes back, and the client reloads the resource using GET. The second DELETE then works fine.

Is the account in your client one that has been present all the time since you did the upgrade? If so, try removing the account from the client, then re-add it and let it resync all the data. Once it has done that, hopefully it will have the change state correctly cached and you won't see the double DELETEs (except for when a real change has taken place on the server that the client has not sync'd).

-- 
Cyrus Daboo