I often run a dispatcher server in sbt ~run.
unfiltered.netty.Http(port)
.handler(plan)
.run()
Http.shutdown()
When I start up my server, it says:
Embedded server running on port 8080. Press any key to stop.
However, only ENTER will stop the server. Unfortunately, ENTER also stops sbt. How can I set up unfiltered so that it actually stops on any key within sbt? I would like pressing a key to stop the server and cause sbt to re-compile and re-run the application.
You can do continuous hot reloading using sbt-revolver and JRebel. There's a free license of JRebel for Scala users.
Start sbt shell.
reStart starts a forked JVM that's exit trapped.
If you installed JRebel correctly, compiled classes from ~products would get loaded into the forked JVM.
See Hot Reloading.
Related
firebase-tools is an NPM package that uses the JVM. It includes an emulators:start command which fires up the JVM, and it has the JVM use some ports (defined in settings) for the emulators' input/output.
I use MacOS. I use a VSCode terminal to start/end the emulators, and define the details of how to start using an NPM script. Like this:
npm run build && firebase emulators:start --only functions,auth,firestore,database --import ./db-temp
In other words, run the build script, then start some emulator services.
So when running the emulators, I:
Open a terminal,
Navigate to the folder containing the script
Run the script (npm run serve)
This gives me a convenient place to get feedback from the emulators for things like errors, network activity, etc.
If I close VSCode using VSCode's X button, everything in VSCode is immediately shut down. When the terminal is closed, the JVM doesn't detect this and quit: it keeps running. Then when I open VSCode and try running my script again, it tells me that the port normally used by the emulators is still open, because the JVM didn't shut down properly. So I have to track down the JVM process, Force Quit it, and then everything works fine.
To shut the emulators down properly, I have to go to the terminal process running the emulators, press ALT+C to close the process, and then close VSCode. This extra step is inconvenient, and easily forgotten.
Can I convince the JVM to shut down when its originating process terminates via a configuration option? I looked through the configuration options on my local machine via java and java -x, and didn't see anything promising, but I am sure that there are people who know much more about Java than I do.
The Firebase emulator has an environment variable available for Java configuration.
I would be open to other options if available: telling VSCode to automatically shut down terminals properly before exiting, for example.
Or must this be handled by firebase-tools itself, perhaps via a ShutdownHook?
After a little conversation with Firebase and some troubleshooting, I learned a few things:
This issue only occurs when running firebase emulators:start --only firestore,database: when they run together, the Firestore process never closes. Start either one by itself and everything closes fine. This leads me to suspect that this is a bug.
This is reproducible outside VSCode, leading me to suspect that the issue has nothing to do with VSCode.
I filed https://github.com/firebase/firebase-tools/issues/4657. We'll see how it turns out.
I need to make sure the server instance always runs the latest code.
Grunt-contrib-watch does reload the watched files, but the server process isn't restarted with the new code, thus old behaviour is still online, new code i.
This Grunt task blai/grunt-express does appear to contain this feature:
serverreload
Setting this option to true will tell express task to start a forever
running server in a child process, and if any of your server scripts
change, the server will be restarted (using a dynamically generated
watch task)
UPDATE: Tried the serverreload option in grunt-express - it doesn't appear to do what I understood, it does not change the running server's code
Any chance to achieve the same feature with gruntjs/grunt-contrib-connect and gruntjs/grunt-contrib-watch?
Example: starting my server from the watch 'tasks' option does run my newest code, but this doesn't appear to be a valid answer (server does not respond to HTTP requests anymore). See my grunt connect gist for more details.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
I am running/debugging an asp.net mvc3 application from within Visual Studio 2010.
Anything static in nature is not called when I re-run the app from within Visual Studio.
(or even something simple like Application_Start())
Each time I want to run the webapp 'properly' I need to kill WebDev.WebServer40.EXE in the task manager before anything static is called again.
q1) Is this normal, and if Yes, why?
q2) If no, then I would expect the ASP.NET Development Server to be restarted each time I restart a debugging session. How can I turn this on?
UPDATE:
Recompiling sometimes causes Application_Start to be called, not always.
I've resorted to calling a batch file in the prebuild, eg
kill_WebServer40.bat
which contains
taskkill /F /IM WebDev.WebServer40.EXE
exit 0
If you embed those two commands directly into the pre-build textarea your compilation will fail if the WebServer isnt running already. This linked helped fix that.
Surprised this wasn't discussed more/previously - when developing an app, as if you have any static data/caches and you want to run the application 'clean' you would run into this issue.
Yes it's normal. It will restart if you touch the web.config or recompile. The development server continues to run the application in the background after you stop debugging.
You can stop the development server in the task tray by right clicking on the icon and choosing stop.
There isn't a way to force a application restart every time you hit debug. This would only be needed for the edge case where you are debugging application start up. Just hit rebuild before debugging and it will have the desired affect.
Some of my builds and plugins make use of private deployment credentials (sometimes read from the file system, sometimes entered and retained in memory via the InteractionService).
Though perhaps it is overparanoid, I try to be careful to minimize the attack surface of software that uses private information, and it feels like bad hygiene to run a server, even on localhost or a UNIX socket, unnecessarily in these builds.
I've looked for a setting I could set in a plugin that would disable server startup unless overridden by the build. So far have not found anything like this. Is there such a setting?
Many thanks!
Update: With the help of Eugene Yokota, as of sbt 1.1.1 there is now a boolean autoStartServer setting. Builds and plugins can prevent the server from starting up automatically by setting autoStartServer := false. (Users can still manually start-up the server by running startServer if they wish.)
As of sbt 1.1.0 at least, the server won't start unless you start the sbt shell, which means that if you're running sbt in batch mode (for example sbt test) in CI environment, it won't have server.
To stop server even in the shell automatically, I've added a JVM flag sbt.server.autostart. So running sbt as sbt -Dsbt.server.autostart=false would do it. You can globally set that by putting that into your SBT_OPTS.
To manually opt-in for server, you can then run:
> startServer
Update: Now that autoStartServer is a setting, you can write the following in ~/.sbt/1.0/global.sbt:
// This is so it works on sbt 1.x prior to 1.1.1
SettingKey[Boolean]("autoStartServer", "") := false