> On Feb 5, 2015, at 7:58 PM, Jacques Distler <[email protected]>
> wrote:
>
>
>> On Feb 5, 2015, at 8:28 PM, Andre LaBranche <[email protected]> wrote:
>>
>> To enable 'accounting' logs for Calendar Server, edit caldavd.plist to add
>> target principals whose activity should be logged, e.g.:
>>
>> <!-- Enable accounting for certain operations -->
>> <key>AccountingCategories</key>
>> <dict>
>> <key>iTIP</key>
>> <false/>
>> <key>HTTP</key>
>> <true/>
>> </dict>
>>
>> <!-- Enable accounting for specific principals -->
>> <key>AccountingPrincipals</key>
>> <array>
>>
>> <string>/principals/__uids__/454D85C0-09F0-4DC6-A3C6-97DFEB4622CD/</string>
>> </array>
>>
>> Once the change is made, HUP the master process or restart the service. The
>> logs are written to an 'accounting' directory adjacent to the other logs.
>
> OK, so I did that, and I now have a directory full of text files containing
> request/response pairs. But they all look like they completed successfully.
>
> Does the server not log ABORTED responses (which, after all, is what we are
> talking about here)?
Hi,
I don't think we log things we cannot send back to the client, just that the
connection was aborted.
In general, this log message means one of two things:
1) We successfully wrote all response data to the client and called
socket.close() and that took more than 20 secs to complete
2) We timed out the connection because the response took more than 5 mins to
generate and when trying to call socket.close() that timed out after 20 secs
Based on your original description, I'm leaning towards #2. We can try enabling
some database logging to see what's happening and how long it's taking. In
caldavd.plist, create a LogDatabase dict that looks like this:
<key>LogDatabase</key>
<dict>
<key>TransactionWaitSeconds</key>
<integer>30</integer>
<key>Statistics</key>
<false/>
</dict>
Then HUP or bounce the service. You should now see entries in error.log
whenever a running database transaction lasts longer than 30 seconds. If you
can link those entries to the requests from your clients with large calendars,
that strongly suggests that these requests are now taking long enough that the
client gives up.
While there is a server-side timeout, the client's timeout (if you're using
Apple clients) is less than our default, so adjusting our timeout will likely
not help.
Once we can identify what types of transactions are taking too long, maybe we
can offer some advice on how to proceed.
-dre
_______________________________________________
calendarserver-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/calendarserver-users
