This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-06-10
Channels
- # announcements (1)
- # babashka-sci-dev (16)
- # beginners (5)
- # calva (3)
- # cider (42)
- # clojure (103)
- # clojure-europe (79)
- # clojure-nl (2)
- # clojure-norway (17)
- # clojure-sweden (2)
- # clojure-uk (8)
- # clojurescript (7)
- # community-development (7)
- # core-async (1)
- # core-typed (18)
- # cursive (9)
- # data-science (1)
- # dev-tooling (14)
- # events (1)
- # fulcro (2)
- # hugsql (2)
- # hyperfiddle (1)
- # leiningen (7)
- # malli (11)
- # re-frame (14)
- # releases (9)
- # ring (18)
- # shadow-cljs (55)
is my cider super outdated or am i missing something?
:jvm-opts ["-javaagent:opentelemetry-javaagent.jar"
"-Dotel.metrics.exporter=prometheus"
"-Dotel.metric.export.interval=5000"
"-Dotel.logs.exporter=none"
]
When i add java agent to jvm options i basically need to cider jack in once (that starts the agent and i don't get the repl) and then jack-in second time to get the repl (and of course exception that port is already in use because prometheus is already started)
why isn't repl starting on the first cider-jack-in
?
cider: 0.25.0I didn't quite understand what you are talking about exactly. Do you refer to the nrepl agent that has been recently introduced to solve the eval interrupt issue on newer Java? BTW, cider-nrepl 0.25.0 (if you refer to that) is very outdated.
No, not really.
I am not referring to anything newly added as i mentioned i am running cider 0.25.0.
I am using older version of cider and i am having trouble starting repl once i add jar in jvm options.
Behavior is as i described cider-jack-in
and repl window never starts in emacs editor but i know for sure that javaagent.jar is started and running in the background.
Question is is this normal behavior?
How do you start cider-jack-in if you want to add jar in jvm options?
Am i missing some config or something in order for agent to be running and also nrepl to start
There's the alternative of launching cider-nrepl from the CLI and cider-connect
ing later.
That would make it particularly clear if there was anything odd during startup
@alexyakushev [cider/cider-nrepl\ \"0.25.1\"\] @U45T93RA6 how do i do this?
https://docs.cider.mx/cider/basics/up_and_running.html#connect-to-a-running-nrepl-server
@U45SLGVHV The versions of CIDER and cider-nrepl are not in sync, so we can't really guess which version of CIDER you're using based on the middleware alone. But cider-nrepl 0.25 in ancient and you definitely should consider updating to a newer version at some point.
@U051BLM8F I upgraded • emacs to 29.3 • cider to 1.15.0 My lein version is "Leiningen 2.9.9 on Java 11.0.23 OpenJDK 64-Bit Server VM" Added open telemetry agent
"-javaagent:opentelemetry-javaagent.jar"
"-Dotel.resource.attributes=service.name=NAME-OF-YOUR-SERVICE"
"-Dotel.metrics.exporter=none"
"-Dotel.logs.exporter=none"
these are under :jvm-opts
in project.clj of the project.
I do cider-jack-in and nothing happens.
Agent jar is started but repl is never started.
Is there a way for me to debug this?@alexyakushev i did,
Leiningen 2.11.2 on Java 11.0.23 OpenJDK 64-Bit Server VM
problem persists...
even if i do lein repl
repl doesn't start.
It's my first time adding jar as jvm option so maybe i am missing something small but obvious 😕Cool. Just to be sure, if you comment out "-javaagent:opentelemetry-javaagent.jar"
, the REPL starts normally?
But if it's there, then even lein repl
does not start. What happens, does it freeze, or exits immediately?
"main" #1 prio=5 os_prio=0 cpu=863.88ms elapsed=34.19s tid=0x00007f584c016800 nid=0x9a06 waiting on condition [0x00007f5853607000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000717d1d640> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt([email protected]/AbstractQueuedSynchronizer.java:885)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly([email protected]/AbstractQueuedSynchronizer.java:1039)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly([email protected]/AbstractQueuedSynchronizer.java:1345)
at java.util.concurrent.CountDownLatch.await([email protected]/CountDownLatch.java:232)
at clojure.core$promise$reify__8591.deref(core.clj:7177)
at clojure.core$deref.invokeStatic(core.clj:2337)
at clojure.core$deref.invoke(core.clj:2323)
at leiningen.repl$server.invokeStatic(repl.clj:340)
at leiningen.repl$server.invoke(repl.clj:320)
at leiningen.repl$repl$run__11656.invoke(repl.clj:450)
at leiningen.repl$repl.invokeStatic(repl.clj:459)
at leiningen.repl$repl.doInvoke(repl.clj:370)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at leiningen.repl$repl.invokeStatic(repl.clj:435)
at leiningen.repl$repl.invoke(repl.clj:370)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$apply.invoke(core.clj:662)
at leiningen.core.main$partial_task$fn__7430.doInvoke(main.clj:284)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.AFunction$1.doInvoke(AFunction.java:31)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$apply.invoke(core.clj:662)
at leiningen.core.main$apply_task.invokeStatic(main.clj:334)
at leiningen.core.main$apply_task.invoke(main.clj:320)
at leiningen.core.main$resolve_and_apply.invokeStatic(main.clj:343)
at leiningen.core.main$resolve_and_apply.invoke(main.clj:336)
at leiningen.core.main$_main$fn__7523.invoke(main.clj:469)
at leiningen.core.main$_main.invokeStatic(main.clj:454)
at leiningen.core.main$_main.doInvoke(main.clj:451)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.main$main_opt.invokeStatic(main.clj:514)
at clojure.main$main_opt.invoke(main.clj:510)
at clojure.main$main.invokeStatic(main.clj:664)
at clojure.main$main.doInvoke(main.clj:616)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.main.main(main.java:40)
"Reference Handler" #2 daemon prio=10 os_prio=0 cpu=1.01ms elapsed=34.18s tid=0x00007f584c1e3800 nid=0x9a0d waiting on condition [0x00007f582869d000]
...
"Finalizer" #3 daemon prio=8 os_prio=0 cpu=0.41ms elapsed=34.18s tid=0x00007f584c1e5800 nid=0x9a0e in Object.wait() [0x00007f582859c000]
...
"clojure-agent-send-off-pool-0" #21 prio=5 os_prio=0 cpu=5.14ms elapsed=33.50s tid=0x00007f584c564800 nid=0x9a1b waiting on condition [0x00007f58203bb000]
...
Looks like the nREPL server started but the subsequent client is never launched/does not connect.
Where is the agent by the way, is it on classpath or in the current directory or where?
Looks like the nREPL server started but the subsequent client is never launched/does not connect.
How do you know this from stack trace?at java.util.concurrent.CountDownLatch.await([email protected]/CountDownLatch.java:232)
at clojure.core$promise$reify__8591.deref(core.clj:7177)
at clojure.core$deref.invokeStatic(core.clj:2337)
at clojure.core$deref.invoke(core.clj:2323)
at leiningen.repl$server.invokeStatic(repl.clj:340)
This part of the stack tells me that at least the REPL server code got executed. Derefing an empty promise is a common way to "freeze" the thread, @(promise)
. That's what the server part is supposed to do.I've tried • moving the jar into /lib and gave it relative path - same behavior • moving jar back to root folder and gave it absolute path - same behavior
What's left to do is to try some other non-invasive agent and see if the REPL starts with it. I think there is something in the default JDK distribution but I can't remember. Otherwise, you can try this one for example: https://github.com/giltene/jHiccup
Or this one: https://github.com/jbellis/jamm
One more thing to try – create a basic tools.deps project with the opentelemetry agent and see if you can get a REPL there.
Current project
Using just
opentelemetry-javaagent.jar
- and also "-javaagent:grafana-opentelemetry-java.jar"
gives me repl
but
;; "-Dotel.resource.attributes=service.name=dev-webserver"
;; "-Dotel.metrics.exporter=prometheus"
;; "-Dotel.metric.export.interval=5000"
;; "-Dotel.logs.exporter=none"
;; "-Dotel.traces.exporter=none"
adding these are the problem.
This basically configures prometheus server to start.
Without those options it's sending data to open telemetry collector (and gives exception)
4318/...] ERROR io.opentelemetry.exporter.internal.http.HttpExporter - Failed to export metrics. The request could not be executed. Full error message: Failed to connect to localhost/127.0.0.1:4318
Basic project - no issues works without and with additional jvm options as expected> Basic project - no issues works without and with additional jvm options as expected Do you mean it works correctly in a basic tools.deps project, with the agent and the exporter enabled?
Yes, that's what i mean. Basic project works without any issues. Both lein repl and cider-jack-in work and i get the repl in both cases.
But any other project that's not basic suffers same issue o.O weird... I will keep digging
Actually only projects that have
:java-source-paths ["java_src"]
in project.clj
Have the issue.
So
:java-source-paths ["java_src"]
:jvm-opts ["-javaagent:grafana-opentelemetry-java.jar"
"-Dotel.resource.attributes=service.name=dev-webserver"
"-Dotel.metrics.exporter=prometheus"
"-Dotel.metric.export.interval=5000"
"-Dotel.logs.exporter=none"
"-Dotel.traces.exporter=none"]
Is a problem.
I still don't understand how this is caused but will continue📣 nREPL 1.2 is out with a faster bencode implementation and JVMTI agent that restores the ability to interrupt evaluations under Java 20+. More details https://github.com/nrepl/nrepl/releases/tag/v1.2.0 Enjoy! Kudos to @alexyakushev for working on those important improvements! You rock! :the_horns: In related news - CIDER 1.15 ("Cogne") is also out! It makes use of nREPL 1.2 and bundles a few improvements to the inspector and flex completion. Check the release notes for more details https://github.com/clojure-emacs/cider/releases/tag/v1.15.0 Cheers!
Cool stuff!
A question about cider-enable-nrepl-jvmti-agent
: does this only apply when using cider-jack-in
and not when cider-connect
?
I guess this answers my question 🙂 https://docs.cider.mx/cider/basics/up_and_running.html#enabling-nrepl-jvmti-agent