This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-15
Channels
- # announcements (7)
- # aws (30)
- # beginners (141)
- # boot-dev (3)
- # cider (48)
- # clara (35)
- # clojure (94)
- # clojure-europe (6)
- # clojure-italy (20)
- # clojure-nl (19)
- # clojure-norway (1)
- # clojure-portugal (6)
- # clojure-spec (7)
- # clojure-survey (3)
- # clojure-uk (93)
- # clojuredesign-podcast (22)
- # clojurescript (20)
- # core-async (54)
- # cursive (29)
- # datascript (1)
- # datomic (4)
- # emacs (2)
- # fulcro (10)
- # jobs (17)
- # juxt (3)
- # kaocha (20)
- # leiningen (20)
- # malli (22)
- # other-languages (7)
- # pedestal (4)
- # perun (2)
- # quil (2)
- # re-frame (7)
- # reagent (3)
- # reitit (31)
- # shadow-cljs (18)
- # spacemacs (11)
- # vim (32)
Mornin'!
måning
Morning
Morning.
It's probably been mentioned already but just a friendly reminder that ClojureBridge London is coming up next month hosted here at Signal: https://clojurebridgelondon.github.io/ We've got a few coaches but more are always appreciated, please do share a link to it on your social media to help spread the word far and wide. We want to make sure people who could benefit from this have a chance of seeing it (they're probably not in the Slack with us if they haven't heard of Clojure yet!) You can also give this a retweet https://twitter.com/ClojureBridgeLN/status/1209083854486720512 😄 please be sure to share it with anyone you think might be interested, we have to spread the word to make sure everyone gets a fair chance of being aware of it.
I'm now changing code in production using a remote repl. The code isn't live-live yet, it's me kicking the tyres. But the ability to do this, and have immediate effect and change the operation of a running system is truly amazing, but oh-so scarey too!
i dunno, the ability to use a repl to change code is obvs great for development, but how is it better than a rolling deploy of a new docker container in production ? you'd have to pull from git on each process, hit the repl on each process - and there are so many things to go wrong, there's a good reason it's scary!
This is me discovering how to do it, and trying something out before I put the code into production mode (and remove jvm switch to startup the repl)
I've used it in staging and production to debug and hotfix where the turnaround would've been SO much longer without it. I love prod / stg repls dearly. Adding a (doto ... tap>) and then getting the front-end engineer to try the thing that failed again is amazing. You can see exactly what's flowing through the system without adding any extra logging. You can be in and out with a solution in a couple of minutes. I think it's something we should embrace and build more tooling / learnings around so we can get the value without the dangers.
It's just fun seeing my colleague hit refresh which results in my Neovim displaying pretty printed data from deep within the function we care about within basically seconds of them asking about the problem.
but if something blows up, like a OOM or some bit of data stops something from working, I don't see anything
we have a java default exception handler which logs to http://sentry.io
(Thread/setDefaultUncaughtExceptionHandler
(reify Thread$UncaughtExceptionHandler
(uncaughtException [_ thread ex]
(log/errorf "Uncaught exception on [%s]." (.getName thread))
(log/errorf ex))))
We use production REPLs quite a lot for debugging -- and occasionally hot fixes when we have something critical on a few processes.
But we can also do a rolling deploy to production in just a few minutes so that's our normal process.
ANZ had an interesting outage in the 80s or 90s. I obviously don’t remember the exact details but they were running Algol on some outdated hardware like CDC orS-360. Anyway, they used to patch the code live using the Algol ALTER statement directly in prod, and many changes never made it into the source files. They did this for years, and then one day there was a power cut. All ATMs in the country (South Africa) were inaccessible for months as developers scrambled to try to rewrite all the code that had just been lost.
I just wasted quite a bit of time before I figured out that if you double = int / int;
in Java you don't get what you expect. :face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth::face_with_symbols_on_mouth:
A certain organisation which will remain nameless kept hundreds of terabytes of backups (incurring costs) which turned out to be totally useless
@folcon i've paid for yourkit
we have the yourkit agent active on all our production containers
it's clojure - the mangling is pretty much the same as with stack traces - it's always been usable
yes - it's helped us diagnose a couple of memory leaks and an async cpu consumption problem
Congratulations, @dharrigan!!! 🎉
Does anyone in here have any experience of http 503 killing an app? (client app using Aleph)
@maleghast first question: what is returning the 503 ? is that from aleph, or a proxy in front of aleph ?
oh, hold on... you are using the aleph client, doh!
Yeah. I am getting a 503 from an API outside my sphere of control, intermittently, and when I do it kills the app, as the 503 appears to throw an un-handled exception
are you using a deferred/catch
on the response from the aleph client ?
so you are derefing the aleph response promise ?
the deref will throw an exception for an error... are you catching that ?
I am not, but it appears I might have to... Seeing as 503 is an HTTP Error, but not an error per se, I was hoping to handle it in-logic. It would appear that the aleph code throws and un-handled exception and kills my app, which is very annoying.
(on a 503 I want to re-add the job to the queue and I'll try it again later, but I want the app to simply continue, rather than fail)
yes, the aleph client throws exceptions for non-200 responses. the good news is that the ex-data in the thrown exception is the response map, so you can trivially handle errors in logic
I don't get unhandled exceptions for 300 responses or 400 responses and I have logic to handle them
oh, ok, maybe i'm misremembering... maybe it's only 500 series responses that throw
https://github.com/ztellman/aleph/blob/master/src/aleph/http/client_middleware.clj#L204
;; Statuses for which clj-http will not throw an exception
(def unexceptional-status?
#{200 201 202 203 204 205 206 207 300 301 302 303 304 307})
Even so, it would appear that the upshot is that any request needs to be wrapped in a (try ...)
because a 50x response will throw an unhandled exception..?
apparently you might be able to turn the exceptions off https://github.com/ztellman/aleph/blob/master/src/aleph/http/client_middleware.clj#L238
here's our aleph-based http client @maleghast, with some sample usage at the bottom - it works nicely for your type of use-case : https://gist.github.com/ba43c83792c1be5d565aff0a8cb37d5e
Thanks very much @mccraigmccraig