31–37 of 37 posts
This is pretty far from what other frameworks and systems can even dream about. Not everyone needs this but when they do need it, I only know about Erlang that can handle it.
Not quite as advanced as erlang, but in PHP's target use cases, it is quite effective.
This is pretty far from what other frameworks and systems can even dream about. Not everyone needs this but when they do need it, I only know about Erlang that can handle it.
Earlier quoted context omitted.
I imagine you would do what erlang does for you, just manually - isolate individual server instances, do the update, then make them public again. Say for example you are updating code in your service's web-tier. Have your LBs not send any more new traffic to the server instance, wait some reasonable length of time until existing connections are completed, deploy, restart, give LBs the A-OK to start traffic up again.…
Ok but what if that server you isolated was holding a long run process. Yes for a web service that serves quick http request and responses you could do that. Not everything is short lived request and response messages. Some sessions and processes are long lived. So you have a socket open and data streaming into it, it is not easy to isolate it. You could say send it a message that says -- start isolating. How do you…
This gets into coding mindset, my impression is that most erlang programmers expect their code to crash whereas most other languages seem to lend themselves to expecting the program _not_ to crash.
I am not very well versed in erlang but my readings so far imply that the graceful handling of crashes is really where erlang/OTP shines. Regardless of the framework, I would say it comes down to proper queuing, being able to safely retry work, and to some extent having some smarts on the clients.
Earlier quoted context omitted.
How would a "reliable message queue + a script engine" be equivalent to a dynamically hot swappable code reloading? Could you elaborate?
The message queue delivers messages to the script engine, running the script new every time. No code is running hot to be swapped into. At the next message, the new code is loaded. Similar to what Erlang does, but much more brittle, less tested, and more fail-prone.
This is pretty far from what other frameworks and systems can even dream about. Not everyone needs this but when they do need it, I only know about Erlang that can handle it.
Lisp does this and has been doing this way before Erlang.
Earlier quoted context omitted.
The message queue delivers messages to the script engine, running the script new every time. No code is running hot to be swapped into. At the next message, the new code is loaded. Similar to what Erlang does, but much more brittle, less tested, and more fail-prone.
Yes.
How do you handle state migration?