This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-29
Channels
- # aleph (2)
- # architecture (1)
- # beginners (5)
- # boot (7)
- # cider (24)
- # clara (28)
- # cljs-dev (7)
- # cljsjs (3)
- # cljsrn (24)
- # clojure (145)
- # clojure-italy (2)
- # clojure-nl (7)
- # clojure-uk (54)
- # clojurescript (159)
- # cursive (49)
- # data-science (8)
- # datomic (23)
- # editors (10)
- # emacs (2)
- # fulcro (123)
- # graphql (12)
- # hoplon (2)
- # java (23)
- # jobs (1)
- # jobs-discuss (2)
- # leiningen (17)
- # mount (5)
- # nrepl (5)
- # off-topic (20)
- # om (2)
- # onyx (25)
- # parinfer (2)
- # pedestal (1)
- # re-frame (8)
- # reagent (7)
- # ring-swagger (1)
- # shadow-cljs (24)
- # spacemacs (7)
- # specter (6)
- # tools-deps (7)
- # vim (2)
Can org.clojure/test.check
be set to :scope "test"
and org.clojure/clojurescript
& org.clojure/clojure
set to :scope "provided"
in onyx-spec?
Yes, that seems fine
@dave.dixon looks like that’s a case where we fail fast and your container / monitored java should start back up
It seems to be due to initial failures connecting to Zk, and then having it fail again when it tries to start the connection. We may be able to improve this case.
It's stuck in CrashLoopBackOff in k8s, error keeps repeating. I'll check ZK.
Actually this part of the message suggests something else: “org.apache.zookeeper.KeeperException.create KeeperException.java: 103 org.apache.zookeeper.KeeperException$UnimplementedException: KeeperErrorCode = Unimplemented for /onyx code: -6 path: "/onyx"
UnimplementedException - May need to know what version of onyx and ZK you’re on.
Onyx 0.13.0.0. We're running ZK as a hosted service via CloudKarafka, I'll try to find out what's happening there. It was all working fine just an hour ago.
Ah weird then. Either way it definitely seems like something to do with ZK but I’m not much help past that.
Can you think of anything I might have been able to do to cause this?
One possibility is that we did bump the ZK client library in 0.13.0 so that we could support SSL. It’s supposed to be backwards compatible, but it’s possible that there is a bad interaction with the hosted ZK version
That might be preventing you from seeing the true error
You could try excluding org.apache.curator/curator-client and org.apache.curator/curator-framework from the onyx dependency, and provide [org.apache.curator/curator-framework "2.9.1"]
in your deps to get back the old library, and try again
Oof. Looks like there are other deps that will need to be overridden. I’ll check with the diff again
FWIW - I'm pretty sure the previous working version was onyx 0.13.0.0 as well.
Yeah, I’m mostly hoping to resolve the unimplemented exception issue so we can get at the real error
You may need to exclude org.apache.zookeeper/zookeeper
and use “3.4.10” instead
All my testing thus far has found the curator/zk deps we bumped to be fine, but I don’t really have any other ideas for debugging it
I guess you could try connecting to zk with the cli and listing /onyx and see if you’re able to poke around there
I rolled back to the container image that was working before, and it still works, so it must be something that we changed recently.
Ah ok. Dependencies seem the most likely cause.
BTW, the big change is that we moved to using tools-deps, which seems to change how deps are resolved.
hello all - I'm using a docker-compose setup based closely on the one generated by the +docker flag to the leiningen onyx template - and the config.edn
is currently the one which was generated. I'm seeing a lot of DEBUG
level logs from the peer container though, which this
:onyx.log/config #profile {:default nil
:docker {:level :info}}
looks like it should preclude