On 12/07/2016 08:22 PM, Vlad Dumitrescu
wrote:
Hi!
Hi Vlad,
I see that the timeouts for the different requests are
diverse and feel a bit "random". Should there be a policy for
how to choose the values? It's possible that different severs
would have different response times.
I fully agree about timeouts, and to be honest you're not far from
the truth with the random approach ;) So far, timeouts were set in a
way that maximized the chances of getting a result without causing
an annoying freeze, and all that only in the context of development
and demos, not in the context of real usage... It's not really what
we can call a "policy" ;)
Do you think a single timeout value for all operations would fit? Or
maybe one per language server? Or does this have to be specific to
each operation...?
It would be much nicer if one could get intermediate
results as they become available (but probably quite difficult
to handle).
Indeed. However, there are not many places in the IDE where a
stream-based approach is useful. Most interactions (commands,
content-assist, hovers...) expect all data to be there synchronously
before presenting them. Introducing asynchronous support is
something that requires some changes in Platform, and there are
ongoing changes such as https://git.eclipse.org/r/#/c/85343/ . But
still, such change expect full results before showing up and do not
consider streaming.
More importantly, probably, what do we do if a request
times out? An async solution would be to run all of these in
separate threads/jobs, use a relatively large timeout value
and if there is a timeout, cancel the request. Eclipse already
may or may not run operations in jobs/threads, so this needs
to be investigated for each case, but I think auto-cancelling
requests on timeout could be added as an utility and used
instead of CompletableFuture.get, What do you think?
We can discuss this on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=508457 and related
bugs. Much work is actually to happen on Platform side.
Cheers,
|