My server is a SheevaPlug with a 1.2 GHz ARM Marvell Kirkwood 88F6281 CPU and 512 Mb of RAM.
I’ll look at the Fdroid logs for the downgrade problem.
Well this is what android.packageinstaller says when I try to downgrade to DADdroid 0.7.7.
D/ApkDownloader( 2153): Download finished: /data/data/org.fdroid.fdroid/cache/temp/at.bitfire.davdroid_63.apk
I/ActivityManager( 847): START u0 {act=android.intent.action.INSTALL_PACKAGE dat=file:///data/data/org.fdroid.fdroid/cache/temp/at.bitfire.davdroid_63.apk cmp=com.android.packageinstaller/.PackageInstallerActivity (has extras)} from pid 2153
I/ActivityManager( 847): Displayed com.android.packageinstaller/.PackageInstallerActivity: +335ms
I/Timeline( 2479): Timeline: Activity_idle id: android.os.BinderProxy@42232460 time:1558298
I/Timeline( 847): Timeline: Activity_windows_visible id: ActivityRecord{421a8880 u0 com.android.packageinstaller/.PackageInstallerActivity t3} time:1558578
I/Timeline( 2479): Timeline: Activity_launch_request id:com.android.packageinstaller time:1562168
I/ActivityManager( 847): START u0 {dat=file:///data/data/org.fdroid.fdroid/cache/temp/at.bitfire.davdroid_63.apk flg=0x2000000 cmp=com.android.packageinstaller/.InstallAppProgress (has extras)} from pid 2479
W/InstallAppProgress( 2479): Replacing package:at.bitfire.davdroid
W/ActivityManager( 847): No content provider found for permission revoke: file:///data/data/org.fdroid.fdroid/cache/temp/at.bitfire.davdroid_63.apk
W/PackageManager( 847): Can't install update of at.bitfire.davdroid update version 63 is older than installed version 66
I/ActivityManager( 847): Displayed com.android.packageinstaller/.InstallAppProgress: +115ms
D/AppDetails( 2153): Getting application details for at.bitfire.davdroid
E/AppDetails( 2153): Installer aborted with errorCode: 2
W/PackageManager( 847): Can’t install update of at.bitfire.davdroid update version 63 is older than installed version 66
I think you’ll have to uninstall and install the old version then. “oandbackup” can help you with preserving your app data
I managed to downgrade!
:; adb push /tmp/at.bitfire.davdroid_63.apk //storage/emulated/legacy/at.bitfire.davdroid_63.apk
5208 KB/s (1314324 bytes in 0.246s)
:; adb shell pm install -r -d /storage/emulated/legacy/at.bitfire.davdroid_63.apk
pkg: /storage/emulated/legacy/at.bitfire.davdroid_63.apk
Success
and now I can sync my calendar again. The requests are very long and too close to the timeout for comfort as they go up to 26 seconds:
192.168.0.254 - stuart [07/Jun/2015:13:37:46 +0200] "PROPFIND /remote.php/caldav/calendars/stuart/contact_birthdays/ HTTP/1.1" 207 22716 "-" "DAVdroid/0.7.7" 4
192.168.0.254 - stuart [07/Jun/2015:13:37:53 +0200] "PROPFIND /remote.php/caldav/calendars/stuart/personal/ HTTP/1.1" 207 1396623 "-" "DAVdroid/0.7.7" 26
192.168.0.254 - stuart [07/Jun/2015:13:39:35 +0200] "REPORT /remote.php/caldav/calendars/stuart/personal/ HTTP/1.1" 207 7110 "-" "DAVdroid/0.7.7" 0
192.168.0.254 - stuart [07/Jun/2015:13:39:38 +0200] "PROPFIND /remote.php/caldav/calendars/stuart/personal/ HTTP/1.1" 207 397 "-" "DAVdroid/0.7.7" 0
192.168.0.254 - stuart [07/Jun/2015:13:39:39 +0200] "PROPFIND /remote.php/caldav/calendars/stuart/contact_birthdays/ HTTP/1.1" 207 411 "-" "DAVdroid/0.7.7" 0
I hope that OwnCloud fixes the REPORT performance problem as I’d like to be able to sync my tasks (feature introduced in DAVdroid v0.8.0 at the same time as the use of REPORT).
I too use a small device to serve owncloud calendar and contact data. I wonder if it would be possible to do one of the following:
Make the connection timeout configurable by the user:
(HttpUrlConnection) conn.setConnectTimeout(sec * 1000);
Just set a longer timeout:
(HttpUrlConnection) conn.setConnectTimeout(300 * 1000);
Do an exponential- or linear-style backoff if the connection gets java.net.SocketTimeoutException; start with 60sec (remember, this is a maximum timeout), and go up by there.
Do you really think this should be work-arounded on client side? A server shouldn’t take 300 seconds to answer such a request.
Maybe increasing would be a good idea nevertheless, but to which value? Do you know reasonable values and references/explanations why these values are reasonable?
Well, like the original poster, I too have a very slow server, which has worked well until now. I don’t want to keep a fast and/or powerful server running all the time just to coordinate calendars on my devices. I am annoyed that ownCloud takes a long time to serve this request, and I wish they would fix that. At the same time, if there is a small fix on the client side that would help in the short term, and would not break things in the long term, I’d like to explore that.
The first option would be to let the user configure the timeout; most users would not change it at all.
The third option could just start with the default timeout, and then an exponential backoff with an algorithm of choice; that’s not different from typical collision detection algorithms for, e.g., layer 2.
I can’t really justify the hard coded 300 seconds in the second option other than it would work for me, and it should not affect the typical user who has a fast server and connection.
I suggest that the third option, an exponential backup, is not worth the time spent on it. You could screw up implementing it, and all to work around a server side bug. If one were to use a client side fix to fix a server side problem, a simple fix such as the second one – extending the time to 300 seconds – is the simplest and therefore safest choice. Whether that is worthwhile on the whole I do not know. After all, what do you do, add it and then remove it a year from now when most (but not all!) servers have upgraded to a less buggy OwnCloud? That’s no good, so maybe it stays around for a very long time.
Just think of the auto-detection and that a server doesn’t respond at all because of mis-configuration. This would mean that when adding an account, you would have to wait 300 seconds (=5 min) in the “Please wait” fragment until the “No CalDAV/CardDAV service found” message appears. I think that would be quite annoying… just as an example what can happen. Also people, might report “My sync process has started and the green wheel is spinning for 4 minutes, but nothing happens” in such a case. I don’t like a timeout of 300 seconds.
Would be interesting to know what timeouts other clients like Thunderbird or Evolution use.
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.
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.
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:
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.
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?
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 :
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.
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 :
- in ResourceFinder, call create(null) and use the default RequestConfig;
- 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.
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.
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