OwnCloud times out since DAVdroid/0.8.0



  • Staying with 0.7.7 is a solution for me. However, it’s not my preferred solution because, for an unspecified amount of time, I am unable to access the additional functionality in >= 0.8.

    In DavHttpClient you build a default RequestConfig with the hard coded 45 seconds for the socket timeout. You then apparently use the class DavHttpClient to create CloseableHttpClients only in DavResourceFinder and DavSyncAdapter.

    Would it solve this problem to, at least :

    1. in ResourceFinder, call create(null) and use the default RequestConfig;
    2. in SyncAdapter, call create(rc) where rc is a new RequestConfig with a longer socket timeout?

    If that would work, I’m willing to fork and follow the davdroid code, and keep applying my patch and build my own local app, until ownCloud is able to reply to REPORT in a faster fashion.


  • developer

    If that would work, I’m willing to fork and follow the davdroid code, and keep applying my patch and build my own local app, until ownCloud is able to reply to REPORT in a faster fashion.

    I’d prefer that because I don’t want to implement workarounds for server bugs in DAVdroid.

    Would it solve this problem to, at least :

    1. in ResourceFinder, call create(null) and use the default RequestConfig;
    2. in SyncAdapter, call create(rc) where rc is a new RequestConfig with a longer socket timeout?

    I suggest to pass a “mode” enum { INTERACTIVE, SYNC } to the constructor instead, so that it can decide which timeouts to use and calling methods don’t have to know RequestConfig internals.



  • Perhaps DAVDroid could have a setting to revert to the 0.7 behavior?
    Although logcat displays a timeout error after about 30 s, the DAVDroid UI does nto indicate an error.

    It is unlikely that ownCloud will fix themselves any time soon. They have a similar problem with Contacts in the Web interface, fetching all of them without pagination, exhibiting the same server behavior:
    Long running php requests of 5 min or more that, if the requests are retried, will add up and take the ownCloud server down.

    You will end up with users that refuse to upgrade and others that don’t understand why DAVDroid does not appear to be working.


  • developer

    Perhaps DAVDroid could have a setting to revert to the 0.7 behavior?

    This is not possible. REPORT is required for supporting task sync and other operations.

    Although logcat displays a timeout error after about 30 s, the DAVDroid UI does nto indicate an error.

    Because this is a soft error. Normally, this error would happen for instance when the device is sync’ing while you drive through a tunnel. It wouldn’t make sense to show a notification in such a time-out case.

    It is unlikely that ownCloud will fix themselves any time soon.

    Why? Do you know whether there is an OwnCloud ticket for that issue and post it here for reference?

    You will end up with users that refuse to upgrade and others that don’t understand why DAVDroid does not appear to be working.

    I recommend to use DAVdroid 0.7 in this case until the OwnCloud bug is fixed.



  • Why? Do you know whether there is an OwnCloud ticket for that issue and post it here for reference?

    I can’t speak for the user, but from my experience ownCloud is very slow at
    fixing bugs in their Contact and Calendar apps, at least regarding the DAV
    parts.


  • developer

    Ok, but we should at least ensure that OwnCloud people are aware of this issue.



  • The ownCloud isse causing this 539: https://github.com/owncloud/calendar/issues/807


  • developer

    Thanks. So I’ll close this issue here, as it’s not a DAVdroid bug.


Log in to reply
 

Similar topics

  • 13
  • 13
  • 7