This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-17
Channels
- # adventofcode (23)
- # announcements (2)
- # aws (11)
- # babashka (181)
- # beginners (59)
- # chestnut (2)
- # clj-kondo (9)
- # clojure (90)
- # clojure-brasil (2)
- # clojure-europe (18)
- # clojure-italy (24)
- # clojure-nl (9)
- # clojure-spec (3)
- # clojure-uk (28)
- # clojured (4)
- # clojuredesign-podcast (3)
- # clojurescript (12)
- # community-development (49)
- # core-async (49)
- # cryogen (5)
- # cursive (16)
- # data-science (1)
- # datascript (7)
- # datomic (54)
- # defnpodcast (4)
- # events (2)
- # figwheel-main (14)
- # fulcro (139)
- # graphql (1)
- # jobs-discuss (6)
- # kaocha (1)
- # luminus (2)
- # malli (3)
- # music (1)
- # off-topic (34)
- # pathom (24)
- # re-frame (13)
- # reitit (5)
- # shadow-cljs (8)
- # test-check (6)
måning
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?
very late to the party here but to pick up on conor here - the answer is ‘lol never’ unless it’s life and death
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/reset
ing 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 🙂
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