Thanks @U10EC98F5, your buffering explanation makes sense however once the initial buffer is cleared the d/loop stops printing messages eg: message! "{\"topic\":\"trade\",\"event\":\"sub\",\"params\":{\"symbol\":\"BTCUSDT\",\"binary\":\"false\",\"symbolName\":\"BTCUSDT\"},\"code\":\"0\",\"msg\":\"Success\"}" message! "{\"topic\":\"trade\",\"params\":{\"symbol\":\"BTCUSDT\",\"binary\":\"false\",\"symbolName\":\"BTCUSDT\"},\"data\":{\"v\":\"2290000000006808487\",\"t\":1657216191559,\"p\":\"20906.82\",\"q\":\"0.001099\",\"m\":true}}" #<Deferred@76fbe620: :not-delivered> I am aware of the heartbeat, the connection stays open long enough for now, I'll add it later. Yes I am new to clojure! thanks for the #() tip now the consume-async has the same behaviour as the d/loop i.e. no messages are ever printed after the buffer is cleared. Yeah i didn't think the max frame parameters would affect it but was trying everything! You got me thinking though, I am running in a container and using graalvm. Tried switching to the clojure image, it didn't help. The connection stays open unless you wait too long which is expected. Not really sure what to do next, I can sit at the repl and eval takes! forever and everything is fine until I use a d/loop or consume-async at which point the fun stops and nothing happens. Unless i s/close! the connection which prints the close message as expected.

Hmmm. First, I would try removing Graal and Docker from the situation entirely, just to simplify the problem. I'm not certain Graal, in particular, is 100% compatible with Aleph yet. My next guess is it's related to logging config somehow. It sounds like logging on other threads goes somewhere else; is there another file to check? If takes are available immediately, they can be processed on the same thread, but if not, a callback is scheduled and that's almost always run on a background thread. This might be one difference between the buffered up mesgs, and new mesgs. One way to test that is not to hunt around for logs, but to append mesgs to an atom as they come in. That won't be affected by logging config. If the number of messages keeps growing after the initial buffered messages, then you know it's just a logging problem.

One of the Graal issues I recall was related to statically-initialized threads being a problem for Graal. There may be some threads missing, which may or may not be fixed with a Graal command line param. Check the GitHub issues. But try removing Graal first 😄

I tried your logging to an atom suggestion first and it works. Which means it's been working all along (with graal in a container) only the println was lost to the abyss. Just like the atom I would have thought stdout would be the same on any thread but clearly that is not the case. Thanks so much for your suggestions! I'll keep them in mind in case I encounter more resistance. Thanks again!👍

Logging in Java (and by extension, Clojure) is way more complicated than it ought to be. If you don’t want to learn the intricacies of logback.xml just yet, give the Timbre logging lib a try. One major issue with bare println is it’s not multi-thread friendly (one line might print in the middle of another line). Still, I can’t recall ever seeing println fail to display anything from other threads before. Exceptions getting swallowed by the default exception handler on other threads, yes, but never println. Not sure if that’s a Graal thing or not… Anyway, glad to hear it’s all working