Large calendar sync leads to 504 Gateway Time-out (above 60 seconds)

Vivi

Hi DAVdroid devs and users !

I’m currently running into a problem with DAVdroid, when trying to sync 5 calendars with my ownCloud server. All of them are recognized properly when I set up the sync - they were even recognized by default with only the base url (great feat btw!).

Four of them, quite reasonnable in size, are sync’ed without any problems. The last one fails to sync, as no events of it appears in my calendar, whereas I would expect all of them to be retrieved. Here some links where you can find debug info and logs (private data replaced). This error doesn’t generate a notification.

In these logs, a particular line captured my attention :
504 Gateway Time-out (calendar url) (60618ms)

I assume that this 60 seconds time-out is preventing the sync. Does it also seem reasonnable to you ? If so, would it be possible to add a user option to configure this time-out delay ? Otherwise, do you have an idea on what’s causing it ?

A couple of final (maybe useful) remarks :

Concerning the size of this last calendar, it has ~4000 events (yup, 10 years condensed in it ^^). For example, the ics file of this calendar is 1,3MB. I did not try, but I guess any 4000 events calendar (or more) would meet the same problem. As you can see in the logs, even not-so-large calendars are taking between 1 and 15 seconds. Not very surprising it can take more than 60 seconds.
I previously used “CalDav Sync Adapter” for this task - I’m switching because I’m annoyed with all sorts of unimportant error notifications it always generates. This app did require a rather long time (we’re talking about ~10 min or so) to sync the whole calendar.
If I try to recover less events (setting a past event time limit at 0 or 30 days, for example), everything goes smoothly and all calendars are sync’ed normally.

Many thanks for your great app, I can’t wait to fully use it

rfc2822

@Vivi said:

This error doesn’t generate a notification.

According to your logs, there are no problems and OwnCloud returns just this limited set and not 4000 events. Which one is the questionable calendar?

Vivi

Thanks for you fast reply.
The questionable calendar is the #14 (“perso”). Where do you see that ownCloud returns a limited set ?

I’m checking to see if CalDav Sync Adapter is currently able to sync the whole ownCloud calendar.

rfc2822

@Vivi I’m sorry, I have overlooked that there’s indeed an error:

2016-03-29 13:32:53 1 [syncadapter.SyncManager] Listing remote entries
2016-03-29 13:32:53 1 [HttpClient$1] --> REPORT https://myserver.org:444/owncloud/remote.php/caldav/calendars/MyAccount/perso/ http/1.1
2016-03-29 13:32:53 1 [HttpClient$1] Content-Type: application/xml; charset=utf-8
2016-03-29 13:32:53 1 [HttpClient$1] Content-Length: 269
2016-03-29 13:32:53 1 [HttpClient$1] Depth: 1
2016-03-29 13:32:53 1 [HttpClient$1] 
2016-03-29 13:32:53 1 [HttpClient$1] <?xml version='1.0' encoding='UTF-8' ?><CAL:calendar-query xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav"><prop><getetag /></prop><CAL:filter><CAL:comp-filter name="VCALENDAR"><CAL:comp-filter name="VEVENT" /></CAL:comp-filter></CAL:filter></CAL:calendar-query>
2016-03-29 13:32:53 1 [HttpClient$1] --> END REPORT (269-byte body)
2016-03-29 13:32:53 1 [HttpClient$PreemptiveAuthenticationInterceptor] Adding basic authorization header for user MyAccount
2016-03-29 13:33:53 1 [HttpClient$1] <-- 504 Gateway Time-out https://myserver.org:444/owncloud/remote.php/caldav/calendars/MyAccount/perso/ (60618ms)
2016-03-29 13:33:54 1 [HttpClient$1] Server: nginx
2016-03-29 13:33:54 1 [HttpClient$1] Date: Tue, 29 Mar 2016 11:33:52 GMT
2016-03-29 13:33:54 1 [HttpClient$1] Content-Type: text/html
2016-03-29 13:33:54 1 [HttpClient$1] Content-Length: 176
2016-03-29 13:33:54 1 [HttpClient$1] Connection: keep-alive
2016-03-29 13:33:54 1 [HttpClient$1] Keep-Alive: timeout=20
2016-03-29 13:33:54 1 [HttpClient$1] OkHttp-Sent-Millis: 1459251173388
2016-03-29 13:33:54 1 [HttpClient$1] OkHttp-Received-Millis: 1459251233992
2016-03-29 13:33:54 1 [HttpClient$1] 
2016-03-29 13:33:54 1 [HttpClient$1] <html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>

2016-03-29 13:33:54 1 [HttpClient$1] <-- END HTTP (176-byte body)
2016-03-29 13:33:54 1 [syncadapter.SyncManager] HTTP/DAV Exception during sync
EXCEPTION at.bitfire.dav4android.exception.HttpException: 504 Gateway Time-out
	at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:317)
	at at.bitfire.dav4android.DavResource.checkStatus(DavResource.java:290)
	at at.bitfire.dav4android.DavCalendar.calendarQuery(DavCalendar.java:88)
	at at.bitfire.davdroid.syncadapter.CalendarSyncManager.listRemote(CalendarSyncManager.java:115)
	at at.bitfire.davdroid.syncadapter.SyncManager.performSync(SyncManager.java:161)
	at at.bitfire.davdroid.syncadapter.CalendarsSyncAdapterService$SyncAdapter.onPerformSync(CalendarsSyncAdapterService.java:64)
	at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)

So, OwnCloud takes too long to scan through the calendar, which causes your Webserver, which apparently has a 60-second timeout for gateways (like FastCGI), to abort the request and send an error message.

With other sync clients, it may work because they use PROPFIND instead of REPORT, which may be faster (but less suitable, because it doesn’t return only events, but all entries, including tasks, which would cause unnecessary sync overhead).

Please note that this timeout is not imposed by DAVdroid (which uses a 120 second read timeout).

I guess your nginx FastCGI timeout is set to 60 seconds, which is the default value. It means that if PHP (running as FastCGI) doesn’t send an answer within 60 seconds, nginx will abort and send a Gateway timeout.

Try setting fastcgi_read_timeout accordingly (for instance, 120 seconds). However, more than 60 seconds to enumerate 4000 entries is quite long (really, it shouldn’t take more than a few seconds when the database is used correctly), so I suggest improving OwnCloud performance, too. See also the OwnCloud timeout thread. Of course, not having calendars with that many entries is also a workaround.

Vivi

Indeed there is a performance issue, but until now I could live with it. I could not think how it could be different between sync clients, though.

I guess this is a good opportunity to raise (again or not) the problem on the ownCloud side, to have a real solution - i.e. not just raising timeout delay or prohibit large calendars.

I will look into it.

Thanks for all yours comments !

rfc2822

@Vivi Just for curiosity: Does it work with fastcgi_read_timeout set to 120?

If yes, it would be great if you could report the problem to the OwnCloud people.

Maybe 405 error codes should be treated as a hard error by DAVdroid, too (to notify the user).

Vivi

I currently do not know how to change that setting, I’m not enough tech-savvy … I have to learn how nginx/FastCGI/etc works before. Do not embarass yourself trying to explain, I just have to search for it by myself.
When I succeed, I will respond to your curiosity.

Concerning a notification, I don’t know what to advise :

On one side, it is indeed helpful to have that kind of information right away, in a notification. In particular for first-time users trying to find out what’s happening, when there is an obvious problem.
On the other side, I’m a bit afraid of the “whining app” effect. CalDav Sync Adapter is that kind of app, adding a new notification for each unsuccessful connection. Notifications start popping for all reasons, such as going in a tunnel, in the subway, connecting to my WiFi, … In the end, unusual are the time of silence

I guess it depends mainly on how it’s done.

For the record, my ownCloud version is 8.1.1.