Increase default socket timeout



  • 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?


  • developer

    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?



  • 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.


  • developer

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


  • developer

    Any news on this?



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



  • 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>
    

  • developer

    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.



  • @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.



  • Create an issue



  • 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


Log in to reply