Switch Language Server functionality to the websocket JSONRPC API endpoint

[vparfonov]

For now we communicate with different Language Services via our REST Services. This is introduce some
problem in case we send a lot of request in the same time form one browser tab. For avoiding such problem need to switch to the webscoket communications.

Here related issues:

• python language server doesn't work python language server doesn't work #4976
• Updating file... popup message interrupts development Add getAll method to UserDao #2154
• Modal message "Initializing Language Server for ts" not disappearing and blocking the ui CHE-2045: Fix recursive clone by ssh #2155
• Cannot re-start php workspace Cannot re-start php workspace #5042
• codenvy IDE hangs/freeze codenvy IDE hangs/freeze  codenvy/codenvy#2146

[tsmaeder]

Hi Vitali,
of course, I'm interested in this. Is the problem the amount of messages or the ordering of the messages?

[vparfonov]

Hello, @tsmaeder i think in amount of messages, like next request start before previous end then we have a lot of opened request we have problem

[bardascat]

@vparfonov
Hello, I don't understand if you provided a work around for this issue or not.
You said: "For avoiding such problem need to switch to the webscoket communications."

I don't understand how can I "switch" to websoket comms, as far as I know websoket are enabled by default in chrome.

Also the problem is happening for JSON files as well.

Catalin

[gazarenkov]

@bardascat I believe the message of @vparfonov is not about you as a user can "switch" it is more about replacing REST implementation of LSs "proxying" service to pure async solution for avoiding communication blockage which can be seen as problems like hanging several types of LSs requests.

[dkulieshov]

Hi guys,

I would like to make some clarifications on the idea that stands behind this task.

At the moment of this writing, the way the client communicate with language server is a bit more complex than we can imagine. Here we have an intermediate REST service that retranslates client/language server messages in both ways. What we believe causes all those mentioned issues is the synchronous way that REST communications are supposed to be performed in. The basic scenario is: we send a request then we receive a response, then we send another request again and so on. The nature of JSON-RPC protocol which is used in LSP does not limit us in that way of synchronization: we can send an arbitrary number of requests, and then receive responses when they are ready to be sent. These two concepts are in this way the opposite.

The most common use-case is: we have several consequent requests and the REST service is waiting for their accomplishment on language server side to send a response to a client. Those unanswered HTTP requests freeze the application/browser or impact client stability in other ways.

What we can do here, is to replace REST protocol based service to JSON-RPC protocol based service that in my opinion fits much better the way language server communicates and functions.