5 ms·

When you are running in production and something is not right, you can attach to the console and see what is going on. This is of course not something that you

by biokoda 13y ago

When you are running in production and something is not right, you can attach to the console and see what is going on. This is of course not something that you should do often, but can be a real life saver. Simulating something that is designed to work with thousands or even millions of users at the same time is pretty much impossible. Hot code loading and attaching to console gives you the option to see what is going on in real time and even fix it if you have to.

phamilton 13y ago
I get that. For persistent connections, it's a life saver. But for a synchronous web service, every connection comes and goes quickly. What do you gain from attaching to the console in that situation that you wouldn't get from the rails console?
- rdtsc 13y ago
  If you only have a socket dispatcher and a quick request processor that servers a page and dies, then that code path is quite minimal. Now you should probably have a supervisor. Your connections could be handled by a connection or socket pool. You could have a database driver. There could be a background processing queue. Now things get interesting, not all those things get torn down and recreated on each request. Even for short lived requests you could attached to a live system and trace one of the short lived requests or set a debug point to see what it does in "slow motion" to so speak. One can use Erlang for quite a bit without touching the distribution (as in distributed nodes across many systems forming a single cluster). Then the shell can help you log in to any other node, transparently. The ability to reload code at runtime is not something many systems can boast. Because that is one case you might touch once you have found the problem, but that is again one thing you can do. You can diagnose loading and system resource utilization as well. If you have a fully-featured system (say downloaded from Erlang solutions) open the shell and type observer:start(). to start the observers. It will launch a GUI window (make sure to have X forwarding if running via SSH). There you can see runtime stats, the application tree, process list, ETS tables. For each application in the tree you can click on the process and see its state.
  - phamilton 13y ago
    Thanks! That makes sense. I see it now. For the benefit of other Rails devs looking in: think about debugging issues with unicorn or passenger on a live system without interrupting service. Then think about being able to fix the code without interrupting service. That's powerful. That's not something I do every day, but I can understand why that's powerful.
shanselman 13y ago
Why should you not do it often?
- alcari 13y ago
  If you find yourself often having to manually access the console on a production system, clearly something in your testing and deployment methodology is horribly wrong.
  - felixgallo 13y ago
    In erlang it's not idiomatic to do it super often, but when a bug does pop up in production, as they tend to do with every known program, it's pretty sweet to be able to look at it and fix it without dropping state or connections.

by biokoda 13y ago

phamilton 13y ago

I get that. For persistent connections, it's a life saver. But for a synchronous web service, every connection comes and goes quickly. What do you gain from attaching to the console in that situation that you wouldn't get from the rails console?

rdtsc 13y ago
If you only have a socket dispatcher and a quick request processor that servers a page and dies, then that code path is quite minimal. Now you should probably have a supervisor. Your connections could be handled by a connection or socket pool. You could have a database driver. There could be a background processing queue. Now things get interesting, not all those things get torn down and recreated on each request. Even for short lived requests you could attached to a live system and trace one of the short lived requests or set a debug point to see what it does in "slow motion" to so speak. One can use Erlang for quite a bit without touching the distribution (as in distributed nodes across many systems forming a single cluster). Then the shell can help you log in to any other node, transparently. The ability to reload code at runtime is not something many systems can boast. Because that is one case you might touch once you have found the problem, but that is again one thing you can do. You can diagnose loading and system resource utilization as well. If you have a fully-featured system (say downloaded from Erlang solutions) open the shell and type observer:start(). to start the observers. It will launch a GUI window (make sure to have X forwarding if running via SSH). There you can see runtime stats, the application tree, process list, ETS tables. For each application in the tree you can click on the process and see its state.
- phamilton 13y ago
  Thanks! That makes sense. I see it now. For the benefit of other Rails devs looking in: think about debugging issues with unicorn or passenger on a live system without interrupting service. Then think about being able to fix the code without interrupting service. That's powerful. That's not something I do every day, but I can understand why that's powerful.

shanselman 13y ago

Why should you not do it often?

alcari 13y ago
If you find yourself often having to manually access the console on a production system, clearly something in your testing and deployment methodology is horribly wrong.
- felixgallo 13y ago
  In erlang it's not idiomatic to do it super often, but when a bug does pop up in production, as they tend to do with every known program, it's pretty sweet to be able to look at it and fix it without dropping state or connections.