Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use asExternalUri For Server Url #173

Conversation

williamsyang-work
Copy link
Contributor

@williamsyang-work williamsyang-work commented Aug 5, 2023

Requires: eclipse-cdt-cloud/vscode-trace-server#11

This allows for automatic port forwarding of trace-server api calls when using remote.

Signed-off-by: Will Yang [email protected]

@williamsyang-work williamsyang-work marked this pull request as draft August 5, 2023 02:09
@williamsyang-work williamsyang-work marked this pull request as ready for review August 9, 2023 17:58
@marco-miller marco-miller self-requested a review August 9, 2023 19:06
@williamsyang-work
Copy link
Contributor Author

williamsyang-work commented Aug 9, 2023

Sometimes after the port is forwarded, the explorer webviews do not refresh to load/show the new data from the trace-server. The user has to navigate away and return to the trace-extension to refresh the views.

There may be other UX flow issues with these changes. I can address them if needed but thought the bugs could be documented and addressed as a separate issue.

@williamsyang-work
Copy link
Contributor Author

williamsyang-work commented Aug 9, 2023

I tested this by:

  1. building the .vsix files
  2. installing them onto vscode while connected via remote-ssh.
  3. using plugin while connected vis remote-ssh.

Using the [Extension Development Host] while connected with remote-ssh also seems to work.
EDIT: You will need to install the .vsix for one plugin since AFAIK only one can be tested at a time using the debugger.
Just make sure that the port is not being forwarded on another open editor.

Copy link
Contributor

@marco-miller marco-miller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

vscode-trace-extension/src/extension.ts Outdated Show resolved Hide resolved
vscode-trace-extension/src/extension.ts Outdated Show resolved Hide resolved
vscode-trace-extension/src/extension.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@marco-miller marco-miller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, yet letting @bhufmann cover the final assessment.

myAnalysisProvider.updateTraceServerUrl(extUriString);
TraceViewerPanel.updateTraceServerUrl(extUriString);
};

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@williamsyang-work a question, what if a user executes the command Trace Server: Start (if stopped) manually using the command palette, shouildn't updateUris() be called as well? Maybe when command serverStatus.started is executed? Please let me know.

Copy link
Contributor Author

@williamsyang-work williamsyang-work Aug 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bhufmann I tested starting and stopping the trace server via command palette and it worked as-is for me.
My understanding is: as long as server url remains the same we don't need to update it. The process on that port can stop, start, restart, etc.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@williamsyang-work When connecting to the remote host and executing the command Trace Server: Start (if stopped) then the server is started, but the port forwarding is not working because updateUris() and hencevscode.asExternalUrl is not executed. Start and stop is still working in this case. I tested that case with a remote running in a virtual machine and I saw it not working.

However, when using the open trace command that starts the server and updateUris() is executed will enable port forwarding for the manual start command.

I think we need to address the manual start case as well.

Copy link
Contributor Author

@williamsyang-work williamsyang-work Aug 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per our discussion updateUris() is now called in the serverStatus.started command. This updates the Trace-Explorer webviews and starts port forwarding.

There seems to be another bug where it shows the server's data accurately, but then changes back to 'No Traces Open: Open Trace' state after some time.

@bhufmann
Copy link
Collaborator

@williamsyang-work I noticed that when I close the remote vscode window, the server is not automatically stopped and keeps running afterwards. I had to go to a shell and kill the process. Do you see this behaviour as well?

@williamsyang-work
Copy link
Contributor Author

@williamsyang-work I noticed that when I close the remote vscode window, the server is not automatically stopped and keeps running afterwards. I had to go to a shell and kill the process. Do you see this behaviour as well?

Yes, this is the behavior I get as well.

@williamsyang-work
Copy link
Contributor Author

williamsyang-work commented Aug 10, 2023

The url that's returned from server.start-if-stopped command is no longer used. Therefore, there is no longer a need for the changes in vscode-trace-server repo.

@williamsyang-work williamsyang-work force-pushed the remote-fixes branch 2 times, most recently from 543eea1 to 8857562 Compare August 11, 2023 16:48
@@ -151,7 +157,7 @@ async function startTraceServerIfAvailable(): Promise<void> {
if (!traceServerExtension || await isUp()) {
return;
}
await vscode.commands.executeCommand(extensionId + '.start-if-stopped');
vscode.commands.executeCommand(extensionId + '.start-if-stopped');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks the local installation. You need to keep the await here. Otherwise opening from file explorer (right mouse click on trace -> Open with Trace Viewer) will fail because server is not ready when continuing.

@@ -151,7 +157,7 @@ async function startTraceServerIfAvailable(): Promise<void> {
if (!traceServerExtension || await isUp()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, the port forwarding is only configured after startTraceServerIfAvailable() is executed. However, in this function isUp() is executed which does a healthCheck() http call to the server. So, it will fail if port forwarding is not done.

So, we need to re-think the execution, i.e. what should be done when and in what order.

Copy link
Collaborator

@bhufmann bhufmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that once the asExternalUri is called the port forwarding is configured and visible in the Ports view. Stopping the trace server doesn't affect that this setting. What can happen that there is a TSP call to the trace server and the forwarded port is not served by the remote server. The HTTP message is pending (use developer tools to reproduce that). Even when starting the sever, these pending messages block all subsequent http requests which makes the trace viewer unusable. To unblock that, the use has to open the Ports view and stop the port forwarding. Doing that the pending message are marked as failed, and afterwards the trace viewer is working again.

I think, we need to investigate a bit more and find a away to avoid the situation with hanging messages and blocked application.

@bhufmann
Copy link
Collaborator

bhufmann commented Aug 11, 2023

@williamsyang-work I noticed that when I close the remote vscode window, the server is not automatically stopped and keeps running afterwards. I had to go to a shell and kill the process. Do you see this behaviour as well?

Yes, this is the behavior I get as well.

Thanks for confirming. I did some investigation and with some logging (to file) I was able to confirm, that the deactivate() method of the vscode-trace-server is being called. However, the call to tree-kill(pid) has no effect. More investigation needed to fix stopping the trace server on exit.

@bhufmann
Copy link
Collaborator

@williamsyang-work I noticed that when I close the remote vscode window, the server is not automatically stopped and keeps running afterwards. I had to go to a shell and kill the process. Do you see this behaviour as well?

Yes, this is the behavior I get as well.

Thanks for confirming. I did some investigation and with some logging (to file) I was able to confirm, that the deactivate() method of the vscode-trace-server is being called. However, the call to tree-kill(pid) has no effect. More investigation needed to fix stopping the trace server on exit.

I did some more digging to figure out what's going on. I think what's happening is that VsCode exits before the treeKill() command is executed. treeKill() spawns external processes to get all the children pids from the parent pid of the trace server launcher. It reads the stdout of the command ps -o pid --no-headers --ppid $ppid and then uses the collected list of pids to call process.kill on it. This is done in a callback, but the parent VsCode application already exited and the hence the no process is killed. I was able to make it work by adding some async/wait/timeout call to delay the execution.

Please note that this can also happen in the local case. I guess, that the shutdown of a local VsCode application takes longer than closing the remote processes.

This allows for automatic port forwarding of trace-server api calls when using remote.

Signed-off-by: Will Yang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants