Unable to setup a subscription because of timeouts



  • Dear developers and community,

    I’ve been using DavX5 for a while already and I really appreciate your work on this amazing app. Thumbs up for the open source concept and for having it in the F-Droid repos!
    With a new job I need to subscribe to a ICS calendar (pretty big one with a slow server unfortunately) and was happy to find ICSx5 in F-Droid. Actually it seems to be the only app in there for ICS subscriptions…
    My problem is now: I can’t really subscribe to the calendar because the responses of the server take too long and the app only gives timeouts. A quick test with curl on my pc revealed that the response takes approx. 60 seconds to arrive.
    Is there a way to change the time before timeout on my android or may it be possible to increase the standard timeout of the app in an update?

    I’d appreciate any help with this.
    Amo



  • 60 seconds to fetch a calendar is absolutely too slow. I would first contact the administrator of the server and report the problem to him. Very often the server is misconfigured or need to be updated to deliver acceptable results.



  • I reached out to an administrator and was told that the server is not really slow but has to put together the calendar live from different sources, which takes up some time. Still, he activated caching for me and the response time (as per tests with curl) got reduced to around 20 seconds.
    Now the app was able to subscribe after a few tries, but still most of the automatic attempts to sync fail with a timeout notification. It also seems to me that manual sync attempts have a higher success rate than the automatic ones, but not sure if it was just luck…
    I think I read that the timeout of the app is set to 45 seconds but it looks to me as if it was 20 seconds. What is the case?



  • Unfortunately, I am still getting timeout notifications on my automatic sync attempts. The response time of the server has been reduced to 20 seconds, which should hopefully be fine now. Is there something else I can check or do?


  • developer

    Until now, the read timeout was 30 seconds. In my opinion, a server shouldn’t require 30 seconds or more to send a reply.

    1. However, I have incread ICSx5 timeout to 60 seconds.
    2. I suggest to change the server so that it prepares your results in background and then just delivers them when requested.

    I have sent an APK with 60 seconds to your email address. Can you tell me whether it’s working for you?



  • Thank you very much for your help!

    Yes, with the APK you sent to me, it is working fine!

    I noticed that the app takes much longer to retrieve the calendar than curl on my desktop. Where curl takes between 15 and 20 seconds, the app takes around 30 seconds, which is probably why it ran into timeouts a lot.

    2: I think this is what the server admin meant when I got told that caching has been activated for me.


  • developer

    @amo said in Unable to setup a subscription because of timeouts:

    Thank you very much for your help!

    Yes, with the APK you sent to me, it is working fine!

    Perfect. Will be included in the next version.

    I noticed that the app takes much longer to retrieve the calendar than curl on my desktop. Where curl takes between 15 and 20 seconds, the app takes around 30 seconds, which is probably why it ran into timeouts a lot.

    I think this is because ICSx⁵ takes a few seconds to process the file. So the 20 seconds are probably the same, but a few seconds are needed for processing before ICSx⁵ updates the “last synced” field.

    2: I think this is what the server admin meant when I got told that caching has been activated for me.

    Are you sure? Caching sounds like “file is cached (and will be served from cache immediately) for some time, but as soon as the file is expired, it will be calculated at the next call (and take 20 secs again)”.



  • Unfortunately I have to reopen this thread as I am encountering the same problem of timeouts.
    In my case it is about shared calendars from popular German e-mail service GMX.

    For about 10 days I have been trying to subscribe to such a shared calendar via ICSx5 - with little to no success due to timeouts.
    I have also tried removing the share of the calendar and reactivating it, generating a new URL but the problem persists.

    Having read through this thread I have now measured via curl the time it takes for the calendar to be delivered.
    Sometimes it seems that the calendar file is delivered within the 60-second timespan but that is just lucky coincidence and not a stable situation.
    More likely, i. e. 9 times out of 10, is that it takes more than 70 seconds, around 72 to 75.
    Obviously this exceeds the timeout of ICSx5 of 60 seconds:

    @rfc2822 said in Unable to setup a subscription because of timeouts:

    1. However, I have incread ICSx5 timeout to 60 seconds.

    As I am not a developer myself, I am not sure of the benefit of a timeout as short as possible.
    Coming from this ignorance I would propose a generous timeout of, let’s say, 120 seconds. This should be enough to cope with any slow server issues now and in the future.
    An alternative could be to include a per-subscription setting of the desired timeout.

    Best regards and thank you for your work!


  • developer

    @lajuga said in Unable to setup a subscription because of timeouts:

    As I am not a developer myself, I am not sure of the benefit of a timeout as short as possible.

    It’s about reactivity. When users enter the URL the first time and click “Validate” or refresh the calendars and have to wait 120 seconds, they will become angry and think the app is hung.

    In my opinion, such calendars should be cached/indexed server side and should be delivered within ms, like it could be expected from modern computers which have enormous computing power. If a calendar takes that long to be delivered, it indicates some problems on the server / in the server software (design).



  • Thank you for your quick reply.

    As I am not a developer myself, I am not sure of the benefit of a timeout as short as possible.

    It’s about reactivity. When users enter the URL the first time and click “Validate” or refresh the calendars and have to wait 120 seconds, they will become angry and think the app is hung.

    Ok, I see.
    But does a timeout force a process to continue that long?
    Isn’t it more that if the request is fulfilled after 5 seconds the user has had a wonderful experience of reactivity and everything is fine and a set timeout never came into play?

    In my case the desired reactivity never occurs since after 60 seconds the request is cancelled because of the timeout limit - even if it would be 10 seconds later.
    Actually I very much would prefer the calendar data to be delivered at all, even if that would mean that I had to wait two minutes for it. Patience is a virtue and seriously: so what if it takes five minutes to update the calendar data?

    If a very generous timeout does not interfere with the software in some mean way and it’s only about the user experience, please consider to either extend the current value of 60 seconds or implement a mechanism for the user to set it themselves.

    You are certainly right, that the server side seems to suck big time, but often - as e. g. in my case - there is simply no way to change anything there.

    Regards.


  • developer

    @lajuga said in Unable to setup a subscription because of timeouts:

    Isn’t it more that if the request is fulfilled after 5 seconds the user has had a wonderful experience of reactivity and everything is fine and a set timeout never came into play?

    No, reactivity doesn’t mean that the desired result is achieved at all, but that it’s achieved in acceptable time. It is not acceptable to wait 1 or 2 minutes for a simple calendar to be refreshed, because this time is far too long for what is possible and indicates severe implementation problems.

    Actually I very much would prefer the calendar data to be delivered at all, even if that would mean that I had to wait two minutes for it. Patience is a virtue and seriously: so what if it takes five minutes to update the calendar data?

    Basically, there’s nothing wrong with that. Let me describe the situation: What whould you think about ICSx⁵ if it took 5 min to start (from the time you click on the launcher icon)? I could say, well it does important things, it calculates the calendar list and renders some colored dots, it takes 5 minutes. Wouldn’t you say that’s unacceptable and choose another app which launches immediately?

    You are certainly right, that the server side seems to suck big time, but often - as e. g. in my case - there is simply no way to change anything there.

    Which leads to an important question: Why does your server take that long? What do server admins/support say about that?


Log in to reply
 

Similar topics

  • 11
  • 10
  • 7