Increase default socket timeout

[AutoImport-opensource21]

I setup davical on a private server and test it with some small calendars. Everything works well. But then I tried to use it for my real calendar. Sync fails, there was no information about the last sync-time and no calendar entries :-(. It shows for a minute the sync symbol. It looks like a Timeoutproblem. With Thunderbird it works well and I set the server-timeouts to 10 minutes, so it seems like a client problem.

    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): I/O error (Android will try again later)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): java.net.SocketTimeoutException
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.conn.LoggingInputStream.read(LoggingInputStream.java:72)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:152)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:270)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
    06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): 	at ch.boye.httpclientandroidlib.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161)

[rfc2822]

06-08 19:44:21.908 E/davdroid.DavSyncAdapter(2669): java.net.SocketTimeoutException

SocketTimeoutException means that a timeout occured while read()ing from the server.

Currently, DAVdroid sets the socket timeout to 45 seconds.

10 minutes seems quite long. How long does your server take? Do you think it’s reasonable to increase the timeout for all other users too? What do you think may a reasonable timeout be?

If the timeout is too long, “stalled” connections won’t abort. For instance, if a broken connection blocks for 10 minutes, it will take 10 minutes per try (if it fails), so in worst case 30 minutes until a synchronization process if finished. Users will certainly wonder why synchronization can take 30 minutes…

[AutoImport-opensource21]

Well the 10 minutes was a value to be absolutely sure to get no timeout from the server. Obviously it’s a long time and I can understand that this shouldn’t be a general default. However with current configuration I’m unable to sync. Could you make it configurable? Or do you have any other idea how to sync the whole calendar?

[rfc2822]

Or do you have any other idea how to sync the whole calendar?

Can you find out why your server takes that long and how long it really takes? 45 seconds should be long enough to send at least something, maybe there is a server misconfiguration?

[AutoImport-opensource21]

So you mean the timeout happens only if there wasn’t sent any information for a time longer than 45 seconds? This sound’s indeed more about a server issue. I must see when I will find the time to analyse it in detail.
Thanks for the response.

[rfc2822]

Yes, please check this. If you have found out anything, please write here to that I can update the status of the issue.

[rfc2822]

Any news on this?

[AutoImport-opensource21]

Sorry no and I’m unsure if I will find the time this year. So feel free to close this issue.

[AutoImport-lmamane]

I’m running into the same issue with contacts. In my case, it is my own davical server; in manual tests (with telnet) replaying the same request that davical timeouts on, the contacts PROPFIND with Depth 1 takes about 90 seconds of returning no data, and then suddenly the whole data is sent in less than one second.

I changed the timeout in the source and rebuilt, now it seems to work. However, because “signed by other key”, I cannot go back to the F-Droid build without destroying the data and running into the same “initial sync timeout” problem again… Making the timeout configurable, or very big, seems adequate to me as a solution.

Here’s the request that takes 90s to return data:

PROPFIND /caldav.php/user/addressbook/ HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Depth: 1
Content-Length: 134
Host: server
Connection: Keep-Alive
User-Agent: DAVdroid/0.6.2
Authorization: Basic XXXXXXXXXXXXXXXXXXx

<propfind xmlns="DAV:">
  <prop>
     <CS:getctag xmlns:CS="http://calendarserver.org/ns/"/>
     <getetag/>
 </prop>
</propfind>

[rfc2822]

Generally, it shouldn’t take 90 seconds to generate the response for this request, so I recommend to have a look at this issue on server side.

[AutoImport-opensource21]

@lmamane Thanks for analyse the issue in detail. Have you created a ticket at DaviCal Gitlab?
Would be great if this issue could be fixed. Unfortunately I didn’t have much experience how to anlyse it at davical.

[AutoImport-opensource21]

Create an issue

[AutoImport-rlees85]

Shame to see this closed. Synology CardDav has the same problem, because a lot of NAS boxes use low power processors, it can take a while to read up 150+ contacts from the NAS and for the NAS to begin its response. DAVDroid times out.

Its all very well saying “well its your servers fault” but this day and age a lot of servers handling contacts and calendars are low power ARM devices not quad core Xeons.

1. Are you REALLY SURE that you won’t make the timeout configurable to make this application work under all circumstances?

2. IF i developed a patch to do this, would you merge it?

I think even 120 seconds would be enough for most to sync properly. 45 is very short, especially as this could catch out ‘normal’ servers on a GPRS link. 120 seconds would still take less than 10 minutes for 4 sync attempts (and if it fails after 4 times the server is down).

Thanks
Rich