Fork me on GitHub

Office Party today


A few people, I notice, are wearing christmas jumpers


a jumper is never just for christmas @dharrigan


So, one thing I'm not sure of - if I have a production clojure application running, and I have a repl also listening for connection - and I connect to that remote repl - can I redefine a function on-the-fly, thus changing the behaviour of a production system without deployment?


I'm going to try that out now! 🙂


But the real question is, "Should you?"


very late to the party here but to pick up on conor here - the answer is ‘lol never’ unless it’s life and death


I know - I'm just learning and understanding what is possible


Doesn't mean I should do that - but if I know I can do it, and how to do it, then it may be useful in the future 🙂


@dharrigan you might also have to bounce an http server if you redefine a handler, depending on how handlers are given to a listener - if they are given by fn value rather than var


I’d only want a REPL on prod if I were to query bits of data on state/user status etc, not actually change anything. Test/Staging yes fine, prod….. there’s a Marilyn gif waiting in the wings right there.


we run a repl on prod for querying state and even doing db updates, but it's a separate process from any of the API instances - mainly just there to see the k8s dns


We have quite a slick use of prepl in dev… our app is multi-tenant, and when we change customers at a repl it requires a downstream service to be restarted with that customers config… So we’ve wrapped integrant’s reset to take the :customer-name; and in a dev repl it’ll dynamically reconfigure the downstream service by connecting through a prepl connection and ig/reseting it with the new config. (In prod the above code paths aren’t deployed; they’re not even included in the jar.)


We run Socket REPLs in quite a few of our production processes all the time. We mostly use them to do debugging/analysis but we do use them to apply on-the-fly fixes without downtime but of course it is pretty "dangerous" to modify live, running code in production... but it's also supremely convenient at times 🙂


Auto scaling does ruin that a little.


Yeah, we don't try to apply patches on clustered services on the fly, I'll be honest, but we have a fully automated deployment process for those so it's not a big deal.


We have a handful of unique processes -- one is an internal-facing web app, a couple are 24x7 background processes -- and it's nice to be able to patch those without downtime.


very late to the party here but to pick up on conor here - the answer is ‘lol never’ unless it’s life and death