Trace Compass Server connection fails in Docker-based deployment

[planger]

Bug Description:

We get an error when opening a trace in the docker-based deployment of CDT.cloud blueprint.

Feedback from Bernd:

The trace server was started by the theia-trace-extension, however it fails querying the server for trace data. The error message is not conclusive; however, my suspicion is that it's because the theia-trace-extension is using "localhost" by default to do the TSP REST API calls. The docker container where the trace server is running, is not "localhost". It is possible to set an environment variable to configure the url for the REST API calls. The environment variable is called "TRACE_SERVER_URL" and needs to be set before the Theia application is started. See https://github.com/eclipse-cdt-cloud/theia-trace-extension#change-the-trace-server-url for more details.

By the way, there was a similar issue when supporting GitPod and we made it work by setting this env variable as shown in the https://github.com/eclipse-cdt-cloud/theia-trace-extension/blob/a11489f71e64946951587f1309bd54d974bdedd7/.gitpod.yml#L24.

If you have any questions, please let me know.

[bhufmann]

Thanks for opening this tracker.

The main reason to query directly the trace server over the TSP REST API from the front-end application, is to avoid unnecessary serialization/deserialization of the JSON data that is used to populate the trace viewer's views. Depending on the view and data size the serialization/deserialization can be non-negligible.

Another reason for avoiding additional serialization is that the TSP data structures need to convert JSON long values to Javascript Bigint to not loose precision due to Javascripts limitation of converting to double values (e.g. for timestamps). So, any serialization that uses regular JSON serialize/serialize would fail. The tsp-typescript-client implementation takes care of the conversion to /from Bigint at the moment.

For both reasons, JSON RCP between Theia front-end and back-end would not be ideal.

Having said that, having the trace server running on the same network as the Theia back-end will have some advantages. We could looking into implementing an HTTP/HTTPs proxy between Theia back-end and front-end (thanks @paul-marechal for the suggestion). This should minimize the added latency and will avoid additional serialization/deserialization. This suggestion will have to be investigated more in detail and prototyped to see if it is a viable solution.

Note: To be able to use the trace-viewer components outside of the Theia environment (e.g. VsCode) the new API has to defined so that it can be replaced by a Theia-independent implementation (which could be just a fallback to the direct connection to the server).