Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-05-24

Channels

#hyperfiddle
<
2023-05-24
>
braai engineer11:05:47

Does electric-xtdb-starter have to be locked to missionary b.27 to work? https://github.com/hyperfiddle/electric-xtdb-starter/blob/master/deps.edn#L14

✅ 2
leonoel11:05:48

it should work with b.30

braai engineer11:05:12

Update: fixed by moving user.clj. See thread. Can’t get :prod build to work - even locally. :dev works fine but prod throws this JS exception: 

Uncaught ReferenceError: $tcoll is not defined
    at cljs.core.TransientHashMap.cljs$core$ITransientAssociative$_assoc_BANG_$arity$3 (main.E2C739D1501A78B5E69CCC0330A5910B.js:2106:374)
    at cljs.core._assoc_BANG_ (main.E2C739D1501A78B5E69CCC0330A5910B.js:991:119)
    at cljs.core.PersistentHashMap.fromArrays (main.E2C739D1501A78B5E69CCC0330A5910B.js:2097:286)
    at main.E2C739D1501A78B5E69CCC0330A5910B.js:3544:69
    at main.E2C739D1501A78B5E69CCC0330A5910B.js:25424:4
c
There is a hint of this during the shadow build: 
------ WARNING #1 -  -----------------------------------------------------------
 File: ~/.m2/repository/org/clojure/clojurescript/1.11.60/clojurescript-1.11.60.jar!/cljs/core.cljs:8266:36
--------------------------------------------------------------------------------
8263 |   (-persistent! [tcoll] (.persistent! tcoll))
8264 |
8265 |   ITransientAssociative
8266 |   (-assoc! [tcoll key val] (.assoc! tcoll key val))
------------------------------------------^-------------------------------------
 variable $tcoll is undeclared
--------------------------------------------------------------------------------
8267 |
8268 |   ITransientMap
8269 |   (-dissoc! [tcoll key] (.without! tcoll key))
8270 |
--------------------------------------------------------------------------------
Could this be a shadow-cljs bug?

✅ 2
xificurC11:05:40

you should apply what I'd call comment-bisecting. Comment out half of your application and rebuild. Keep repeating until you narrow down on a specific issue. At that point it's easier to point fingers

xificurC11:05:25

The worst I hit this year was a google closure optimization bug

braai engineer11:05:21

This happens even with :optimizations :none during uberjar build (using shadow/compile instead of shadow/release). Not sure if that applies here?

xificurC11:05:34

sure, probably not a GCC bug in this case, but the bisect should still help

braai engineer23:05:28

Fixed by moving user.clj to src-dev/user.clj and using :extra-paths. The user namespace that prevented the logging .class from being compiled. It’s a footgun: https://www.karimarttila.fi/clojure/2023/03/14/creating-uberjar-for-clojure-fullstack-app.html

braai engineer13:05:05

Update: fixed (see below). I’m running a pure :dev build on a “prod” machine because I’m blocked on :prod build issues. Everything works but after a while, the connection drops with this in the server logs: 

ERROR hyperfiddle.electric-jetty-adapter: Websocket error
java.lang.NullPointerException: Cannot invoke "clojure.lang.IFn.invoke(Object)" because the return value of "clojure.lang.RT.aget(Object[], int)" is null
	at hyperfiddle.electric_jetty_adapter$electric_ws_adapter$on_text__78555.invoke(electric_jetty_adapter.clj:76)
	at ring.adapter.jetty9.websocket$proxy_ws_adapter$fn__78396.invoke(websocket.clj:157)
Is this expected? It can’t seem to reconnect after dropping (average Internet here in ZA). Is this NPE the cause of reactor breaking, or the symptom of a broken reactor?

✅ 2
braai engineer14:05:20

Update: fixed by moving user.clj to src-dev/user.clj and adding "src-dev" to :extra-paths of :dev build alias. user namespace is footgun that prevents logging .class from being built AOT: https://www.karimarttila.fi/clojure/2023/03/14/creating-uberjar-for-clojure-fullstack-app.html --- OK, I’ve managed to reproduce the Reactor failure using electric-xtdb-starter repo with minimum changes to get a uberjar out via src-build/build.clj and :optimizations :none. Repo: https://github.com/theronic/electric-xtdb-starter (soz I pushed to master branch) I tried with both Jetty 9 & 10. With Jetty 10 I don’t see any logs, but 9 shows this in server logs: 

WARN  org.eclipse.jetty.websocket.common.WebSocketSession: Exception while notifying onClose
java.lang.NoClassDefFoundError: clojure.tools.logging.impl.LoggerFactory
	at hyperfiddle.electric_jetty_adapter$electric_ws_adapter$on_close__14039.invoke(electric_jetty_adapter.clj:66)
	at ring.adapter.jetty9.websocket$proxy_ws_adapter$fn__13906.invoke(websocket.clj:159)
	at ring.adapter.jetty9.websocket.proxy$org.eclipse.jetty.websocket.api.WebSocketAdapter$WebSocketPingPongListener$12d400b6.onWebSocketClose(Unknown Source)
	at org.eclipse.jetty.websocket.common.events.JettyListenerEventDriver.onClose(JettyListenerEventDriver.java:149)
	at org.eclipse.jetty.websocket.common.WebSocketSession.callApplicationOnClose(WebSocketSession.java:394)
	at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.close(AbstractWebSocketConnection.java:225)
	at org.eclipse.jetty.websocket.common.WebSocketSession.close(WebSocketSession.java:130)
	at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.openSession(AbstractEventDriver.java:221)
	at org.eclipse.jetty.websocket.common.WebSocketSession.open(WebSocketSession.java:493)
	at org.eclipse.jetty.websocket.common.WebSocketSession.onOpened(WebSocketSession.java:459)
	at org.eclipse.jetty.io.AbstractConnection.onOpened(AbstractConnection.java:213)
   ...
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036)
	at java.base/java.lang.Thread.run(Thread.java:858)
Caused by: java.lang.ClassNotFoundException: clojure.tools.logging.impl.LoggerFactory
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:827)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1096)
	... 28 common frames omitted
Steps to repro: 
HYPERFIDDLE_ELECTRIC_APP_VERSION=`git describe --tags --long --always --dirty`
clojure -X:build uberjar :jar-name "app.jar" :version '"'$HYPERFIDDLE_ELECTRIC_APP_VERSION'"' :optimizations :none
java -DHYPERFIDDLE_ELECTRIC_SERVER_VERSION=$HYPERFIDDLE_ELECTRIC_APP_VERSION -jar app.jar
Same results for Missionary b.30.

✅ 2
Geoffrey Gaillard14:05:26

Caused by: java.lang.ClassNotFoundException: clojure.tools.logging.impl.LoggerFactory It looks like you don’t have the same logging deps between dev and prod. You might want to look at clojure.tools.logging documentation and configure your logger.

braai engineer14:05:35

Where am I overriding logging deps in prod? deps are from here: https://github.com/hyperfiddle/electric-xtdb-starter/blob/master/deps.edn

Geoffrey Gaillard15:05:39

Ok this is not it, sorry. Still the issue is related to a clojure.tools.logging misconfiguration. Maybe a dependency conflict?

Geoffrey Gaillard15:05:57

Looks like an issue with the uberjar. This works in the meantime: 

HYPERFIDDLE_ELECTRIC_APP_VERSION=`git describe --tags --long --always --dirty` clojure -J-DHYPERFIDDLE_ELECTRIC_SERVER_VERSION=$HYPERFIDDLE_ELECTRIC_APP_VERSION -M -m prod

Geoffrey Gaillard15:05:08

After running it you’ll get No implementation of method: :latest-completed-tx of protocol: #'xtdb.api/PXtdb found for class: clojure.lang.Var$Unbound It’s because https://github.com/theronic/electric-xtdb-starter/blob/63950b7328fca1da1c6055e26223945965391081/src/app/todo_list.cljc#L68 you are using binding sequentially. In clojure, binding binds in parrallel, so you want this~ Edit: I missread. The reason is user.clj is not loaded

braai engineer16:05:53

Aha, it’s because in the prod main, !xtdb is not set like in the dev main: 

(defn main [& args]
  (println "Starting XTDB...")
  (alter-var-root #'!xtdb (constantly (start-xtdb!))) ...
This is probably the reason why it’s error’ing out in my repo too 🙂 Now to fix the logging issue…

braai engineer16:05:27

@U2DART3HA OK so I have to use -J flag to set jvm property. hmm, I’m getting this error despite setting the env vars: (I’m not familiar with -J-D syntax)

braai engineer23:05:13

Fixed by moving user.clj to src-dev/user.clj and using :extra-paths. The user namespace that prevented the logging .class from being compiled. It’s a footgun: https://www.karimarttila.fi/clojure/2023/03/14/creating-uberjar-for-clojure-fullstack-app.html

🙏 2
braai engineer16:05:29

Has anyone managed to get a working :prod (uberjar) going with the Electric XTDB starter repo?

✅ 2
braai engineer11:05:32

Thanks, will try that too 🙂

braai engineer21:05:15

Under the Deployment heading in the electric-starter-app README, it states to run build-client, then uberjar step, but the uberjar step includes build-client. So many ppl trying out Electric will be building client twice (I did this for a long time until I read build.clj). Maybe can move build-client to its own code block? https://github.com/hyperfiddle/electric-starter-app#deployment

✅ 2
Dustin Getz16:05:02

This is a readme-only fix right?

braai engineer17:05:02

Yes, assuming there is no another reason to run build-client separately (maybe in parallel).

Dustin Getz16:05:45

this is done, thanks