Don't start birdseye if it's already running
alexmojaki opened this issue · comments
If birdseye is running outside of the extension, it fails to start because the port is already taken.
wierd - when i run two birdseye's on the same port they both work. Maybe it is a OS-specific thing? What OS are you using?
I'm using Mac, and that's normal behaviour on Linux too. I don't see how it could work otherwise - if two processes use the same port, how do you make sure a client talks to the right one?
if two processes use the same port, how do you make sure a client talks to the right one?
No clue but windows seems to think it's okay :/
I have a ubuntu VM so I can reproduce the problem on there.
I reproduced the problem in my VM.
simple solution to this: run birdseye in vscode under a different port. Let's say 7778, not sure if the exact number matters or not.
benefits: dead simple and easy. No need to find cross-platform way of detecting if birdseye is running.
drawbacks: if you are really unlucky you might happen to run birdseye using the same port vscode uses at the same time as running birdseye vscode.
Thoughts?
oh wait, it looks like you expose a environment variable to check if its running
if not os.environ.get('BIRDSEYE_SERVER_RUNNING'):
In that case I just need to skip launching birdseye if that environment variable is present. Maybe display a info message to user telling them that birdseye is already running.
Checking for a environment variable in javascript is super easy, not even any imports required.
console.log(process.env.BIRDSEYE_SERVER_RUNNING)Nevermind, that is just a travis setting.
Back to my original question, i guess - launch vscode birdseye under different port?
Yes, it's just a travis setting.
You need to:
- Allow the user to configure which port birdseye runs on.
- When the user requests to show birdseye, make an HTTP request to localhost:
- If the request fails completely, there's no process running there, so run your birdseye.
- If the request succeeds, check the content for some defining feature like the text "Bird's Eye".
- If the content is there, don't do anything, you're good to go. Display the browser panel.
- If the content is not there, show an error message complaining that something else is running on .
Allow the user to configure which port birdseye runs on.
Already done :)
If the request fails completely, there's no process running there, so run your birdseye.
If the request succeeds, check the content for some defining feature like the text "Bird's Eye".
It sounds a lot easier to just change the default port.
Now that I fixed #8 the worst case scenario is that a user happens to use the same port for something else, in which case they see the error and they can just change the port.
Reopening in case of further discussion
You don't have to reopen issues just in case, it's possible to discuss on closed issues :)
My problem with changing the default port is that users may sometimes decide they'd like to open birdseye in a browser. Ideally this should work effortlessly without requiring anyone to look through documentation or configuration, which they might never think to do. They could solve the problem by running another server themselves, but it's likely they won't think to do that if or even know how if their only experience with birdseye is through this plugin (which will hopefully be the case sometimes). Plus this plugin is meant to make using birdseye as convenient as possible. Finally, birdseye should hopefully be usable by complete beginners to programming to help them learn, and for them any usability problem such as asking them to start a server is significantly magnified.
I don't think it's likely that a user would open vscode's birdseye in a browser. If they are using the VSCode extension they would look at the preview. Using a birdseye extension for vscode would be kind of pointless if you did not use vscode.
I've opened a FAQ issue (see #9) in case users do run into this.