we upgraded cider-nrepl to 0.55.1 and today we had the case, where 11 cpus ran at 100% for around 45 minutes until we killed the process. I ran jstack and it looks like it has to do with latest changes to track-state
"clojure-agent-send-off-pool-7" #88 [3077360] prio=5 os_prio=0 cpu=2571688.20ms elapsed=3094.35s allocated=663M defined_classes=6 tid=0x00007fc44400a090 nid=30
0007fc4275fc000]
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.get(java.base@21.0.3/WeakHashMap.java:415)
at cider.nrepl.middleware.track_state$get_metadata_if_changed_QMARK_.invokeStatic(track_state.clj:74)
at cider.nrepl.middleware.track_state$get_metadata_if_changed_QMARK_.invoke(track_state.clj:69)
at cider.nrepl.middleware.track_state$compute_var_meta.invokeStatic(track_state.clj:96)
at cider.nrepl.middleware.track_state$compute_var_meta.invoke(track_state.clj:89)
at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace$fn__96498.invoke(track_state.clj:128)
at clojure.lang.PersistentHashMap$NodeSeq.kvreduce(PersistentHashMap.java:1309)
at clojure.lang.PersistentHashMap$BitmapIndexedNode.kvreduce(PersistentHashMap.java:804)
at clojure.lang.PersistentHashMap$NodeSeq.kvreduce(PersistentHashMap.java:1314)
at clojure.lang.PersistentHashMap$BitmapIndexedNode.kvreduce(PersistentHashMap.java:804)
at clojure.lang.PersistentHashMap$ArrayNode.kvreduce(PersistentHashMap.java:468)
at clojure.lang.PersistentHashMap.kvreduce(PersistentHashMap.java:238)
at clojure.core$fn__8555.invokeStatic(core.clj:6987)
at clojure.core$fn__8555.invoke(core.clj:6967)
at clojure.core.protocols$fn__8283$G__8278__8292.invoke(protocols.clj:174)
at clojure.core$reduce_kv.invokeStatic(core.clj:6998)
at clojure.core$reduce_kv.invoke(core.clj:6989)
at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace.invokeStatic(track_state.clj:123)
at cider.nrepl.middleware.track_state$compute_var_metas_for_namespace.invoke(track_state.clj:114)
at cider.nrepl.middleware.track_state$ns_state.invokeStatic(track_state.clj:208)
at cider.nrepl.middleware.track_state$ns_state.invoke(track_state.clj:203)
at cider.nrepl.middleware.track_state$initial_project_state$fn__96550.invoke(track_state.clj:257)
at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:65)
at clojure.core.protocols$fn__8270.invokeStatic(protocols.clj:135)
at clojure.core.protocols$fn__8270.invoke(protocols.clj:123)
at clojure.core.protocols$fn__8229$G__8224__8238.invoke(protocols.clj:19)
at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:31)
at clojure.core.protocols$fn__8262.invokeStatic(protocols.clj:74)
at clojure.core.protocols$fn__8262.invoke(protocols.clj:74)
at clojure.core.protocols$fn__8203$G__8198__8216.invoke(protocols.clj:13)
at clojure.core$reduce.invokeStatic(core.clj:6965)
at clojure.core$reduce.invoke(core.clj:6947)
at cider.nrepl.middleware.track_state$initial_project_state.invokeStatic(track_state.clj:253)
at cider.nrepl.middleware.track_state$initial_project_state.invoke(track_state.clj:250)
at cider.nrepl.middleware.track_state$calculate_changed_project_state_response.invokeStatic(track_state.clj:315)
at cider.nrepl.middleware.track_state$calculate_changed_project_state_response.invoke(track_state.clj:294)
at cider.nrepl.middleware.track_state$make_transport$reify__96576$fn__96578.invoke(track_state.clj:341)
at clojure.core$binding_conveyor_fn$fn__5842.invoke(core.clj:2047)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask.run(java.base@21.0.3/FutureTask.java:317)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.3/ThreadPoolExecutor.java:1144)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.3/ThreadPoolExecutor.java:642)
at java.lang.Thread.runWith(java.base@21.0.3/Thread.java:1596)
at java.lang.Thread.run(java.base@21.0.3/Thread.java:1583)
Oof, sorry to hear that. Does this reproduce reliably in one project? In all projects?
@holger311 @kommen have you been able to reproduce it already?
I assume this didn't happen on an open-source project?
@alexyakushev no, but can add you on github if it helps
itโs not exactly light on deps either
All the merrier, recent track-state changes were specifically done for large projects.
It would be easier to find out what's going on if I had the access to the project, but I understand if it is too hard process-wise
@alexyakushev sent you an invite on github
thanks a lot for you help btw!
Np. I break it, I fix it ๐
no luck in reproducing it til yet
we tried: connecting with cider and evaling some namespaces and code (I saw sate messages in the nrepl log). disconnecting/connecting multiple times. connecting two sessions at the same time.
@alexyakushev any idea what else we could have tried?
what would we lose/miss if we remove it from prod?
Very little. I suggested that to @mkvlr in DM.
yes, we will do this and remove the middleware for now in prod. thanks!
If you encounter this ever again, please report back here. I also created an issue: https://github.com/clojure-emacs/cider-nrepl/issues/936
This issue is hopefully fixed in cider-nrepl 0.55.7.
is it normal that when expanding a macro with C-C RET that I loose meta data? maybe thereโs something wrong with my macro, but I get the feeling that Iโm loosing meta data. for example when I expand the following.
(dsdefn f
([[a b] c d] 12)
([a [b c] d] 13)
([a b [^Ratio c d]] 14)
([a b [^integer? c d]] 15)
([a b [^Number c d]] 16)
([a b [^Double c d]] 17))
What I see is the following.
(def f
(rte-case/dsfn
([[a b] c d] 12)
([a [b c] d] 13)
([a b [c d]] 14)
([a b [c d]] 15)
([a b [c d]] 16)
([a b [c d]] 17)))
Hereโs the code for the macro. Do I need to do something special to keep metadata?
(defmacro dsdefn
[name & forms]
`(def ~name (dsfn ~@forms)))metadata is not typically visible
there is a print-metadata option you could set
bravo!
(doc *print-meta*)
-------------------------
clojure.core/*print-meta*
If set to logical true, when printing an object, its metadata will also
be printed in a form that can be read back by the reader.
Defaults to false.
this is what might be helpful to youIs it possible to configure Cider so that it would support the https://github.com/clj-commons/formatter/issues/9#issuecomment-446167649 indentation used by https://github.com/oakmac/standard-clojure-style-js/?
I've configured clojure-mode to use the 'always-indent style https://metaredux.com/posts/2024/02/19/configuring-fixed-tonsky-indentation-in-clojure-mode.html. However, this doesn't recognize the Rule 3 exception.
So, for example, if I have the following piece of code:
(foo bar
baz
quax)
...and I run indent-region, I get this:
(foo bar
baz
quax)
What I'd hope to get is this:
(according to Rule 3, quax should be aligned)
(foo bar
baz
quax)That's what I expected too ๐ซค
For the record, I also asked this question in the Standard Clojure Style repo (https://github.com/oakmac/standard-clojure-style-js/issues/194)
I'm not expert on this, but I doubt it is possible. Enforcing such rule would make indentation depend on previous indentation โ a mechanism we didn't have anywhere before.