Extended default timeouts
Issue #35
new
A test drive using a rather busy line (simulated by a heavy background uploading process on the same DSL line) resulted in a rather lot of timeouts. As mobile use more and more is a trend, it might make sense to extend the default timeouts to get along with busy lines. The benefits are improved stability in downsized environments. The disadvantage is reduced agility due to longer wainting "if nothing goes on". It might be hard to find a good compromise value, but it might be worth at least optimizing a bit into the direction of "bad" lines.
Comments (3)
-
repo owner
-
reporter
That's a really good question, and I don't have a proposal actually.
I think it is best to face the consequences: If I understand correctly then a timeout of let's say ten seconds will lead to the fact that the software will "hang" for that time, as the API us blocking. That might be OK for some functionality (like sending a really big avatar for example) but not necessarily for all functionalities (like sending a short message for example). So the optimal solution might be to have factors regarding the "extension" of the timeout. This means, a default timeout of 5s would effectively 20s for sending an avatar if the Babbler implementation assumes a factor of 4 due to the nature of avatar sending. While this might be the best (since adapted to the job) solution, it is the most complex one and beyond the what we can handle safely I think.
As you plan to use asynchronous APIs anyways, it might be a good idea to suspend this ticket until that change is implemented?
-
repo owner
Ok, let's rethink this later. There's a easy solution by just configuring a custom timeout if the default one doesn't fit your environment.
- Log in to comment
Ok, the current default timeout is 5s. What do you think is a better value? When using Java 8's async API, there might be another approach anyway.