OwnCloud times out since DAVdroid/0.8.0

[AutoImport-luigibai]

Don’t set the long timeout when adding an account, just on the sync calls. In most cases, for most people, their sync won’t take the whole 5 minutes, so they should never see a problem. And for people like stuart and me, we can start using DAVdroid again without downgrading to < 0.8.

If you don’t like a timeout of 300sec, then would you consider letting the user configure it? Most people won’t, so they won’t have any more issues than they do now, and DAVdroid will start working for me again.

I can confirm that Thunderbird/Icedove works like DAVdroid < 0.8 - it doesn’t use the REPORT query. I can still see my calendars on my desktop.

[rfc2822]

Well, socket timeouts could continue to happen for any reasons: slow server, slow connection, giant reply message (does anyone ever delete old calendar entries?), etc. I think in general having /some/ reasonable way to handle timeouts is not a bad idea, even if the general case is DAVdroid connecting to fast servers over fast connections.

The timeouts you mention are handled in different ways:

• ConnectTimeout is the timeout value for connecting to the socket (regardless of the reply), i.e. if the timeout is 40, a server may take 39 seconds to reply with SYN+ACK, while
• SocketTimeout defines how long a read() call may block until a SocketTimeoutException is thrown.

The first timeout is usually not a problem and a Web server thing, while the second one is given by the actual CalDAV/CardDAV application.

• Slow connection: the connection timeout applies. Please note that in case of a connection timeout (for instance, because mobile network is connected, but not able to transfer data [e.g. train tunnel] for 45 seconds) the sync process will fail softly and Android will retry again in a short time.
• Slow server: the socket timeout applies.
• Giant reply message: no timeout will occur, except when the server takes too long to calculate the reply (in this case: see “slow server”).

Don’t set the long timeout when adding an account, just on the sync calls.

Do you really think DavHttpClient should have different timeouts for different actions? This would mean implementing a “mode”, for instance interactive mode and sync mode.

Most people won’t, so they won’t have any more issues than they do now, and DAVdroid will start working for me again.

I recommend to stay with DAVdroid 0.7.7 until the OwnCloud problem is fixed. Would that be a solution for you?

[AutoImport-luigibai]

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.

[rfc2822]

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.

[AutoImport-rob9]

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.

[rfc2822]

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.

[AutoImport-untitaker]

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.

[rfc2822]

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

[AutoImport-rob9]

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

[rfc2822]

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