This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (35)
- # boot (111)
- # cider (12)
- # clojure (295)
- # clojure-android (2)
- # clojure-dev (12)
- # clojure-dusseldorf (9)
- # clojure-finland (1)
- # clojure-greece (7)
- # clojure-italy (24)
- # clojure-norway (1)
- # clojure-poland (7)
- # clojure-russia (14)
- # clojure-sg (1)
- # clojure-spec (29)
- # clojure-uk (25)
- # clojurebridge (1)
- # clojurescript (157)
- # clr (3)
- # cursive (3)
- # datomic (55)
- # docker (6)
- # hoplon (4)
- # juxt (11)
- # leiningen (13)
- # luminus (1)
- # lumo (3)
- # mount (1)
- # off-topic (47)
- # om (43)
- # onyx (35)
- # re-frame (33)
- # reactive (2)
- # reagent (4)
- # rum (3)
- # schema (5)
- # specter (5)
- # test-check (63)
- # vim (15)
- # yada (14)
This is probably a simple question: I’m hitting a ‘unable to resolve symbol’ when trying to run a workflow in test. Right now the job is spun up in test. It contains a catalog entry that refer’s to a function from a namespace in the main codebase. Since that function is only represented as a catalog entry I don’t refer/import it anywhere directly in the test namespace. When the job runs that fn can’t be found. How do I ensure that it and others like it can be resolved?
So, it resolves it if I explicitly require the function in the enclosing namespace that runs the job. Is there any other way to ensure it can be found?
@georgek That’s about it. It’s the same way as in Clojure. To ensure something is resolvable on the classpath, you need to require it.
I have hit a problem with punctuation triggers working on 0.10.beta9. From what I can tell, onyx.peer.task-lifecycle/checkpoint-state throws an "Unfreezable type: class clojure.lang.Var" exception, possibly because it's trying to serialize the trigger's :pred-fn? Exception is thrown with any predicate function I use, even (constantly false). Not entirely sure what to do next, other than remove the trigger entirely and workaround it using another trigger strategy.
@kjothen I’ll take a look, that’s a perplexing one. We don’t serialize the pred-fn in the checkpoints
If you can Gist us the full stack trace, that’d be appreciated. Also your window & trigger definition.
@michaeldrogalis Same behaviour under beta12 too. The :pred-fn was just a (bad) guess, I'll prepare the gist (which is tricky because my work PC cannot access slack or Gist!) If it helps, I have a global window using the built in conj aggregator and the (new!) emit trigger work. I'm only using the punctuation trigger because I need to ensure the window state is emitted downstream before the job competes.
@kjothen If the stack trace blew up at
onyx.peer.task-lifecycle/checkpoint-state, you probably have something in your Conj aggregate that can’t be deserialized.
I’m not sure how Nippy was able to freeze something it couldn’t thaw, though.
Sounds like a var, rather than the value it contains, is making its way into the checkpoint state.
Oh - your message says Unfreezable, not unthawable. Okay this makes more sense.
@michaeldrogalis @lucasbradstreet I would agree, but it is odd that it only happens when I have a punctuation trigger: a segment trigger works fine with the checkpointing of state, and both triggers use the same emit function. Also, it seems to occur directly after the :job-competed event-type has passed through the pipeline. Anyhow, not much you can do without a reproducible use case, so I'll get on with that. Thanks!
@kjothen Okay, that’s good evidence for a bug around that trigger type then. Thanks, we’ll get it fixed after we get some more info!
@michaeldrogalis @lucasbradstreet I've included the gists below, hoping you'll spot something obvious! 🤞 lein new onyx-app onyx-trigger-problem project.clj https://gist.github.com/kjothen/0784b24a7be91bcaf753fa4793dbfa63 basic.clj https://gist.github.com/kjothen/6ad77ed36739a0904b75929b810c6c56 onyx.log https://gist.github.com/kjothen/eeea73a9c93ab33cdc5abaad77a44b74
@michaeldrogalis sure, just wasn't convinced it was an issue just yet, could entirely be my bad. But I'll post something just in case.
@michaeldrogalis that's super. So very keen to make use of the trigger emit functionality, but I do need to have processed all segments in a batch job into an aggregate for downstream, hence the punctuation trigger. Thanks for looking into it!
@kjothen Sure, no problem! I see the issue, deciding on what the most appropriate fix is..
It needs review & tests, but if you want to pull this down it should get you unstuck.
@michaeldrogalis magnificent, thanks again! I'll certainly be trying it out in anger tomorrow (100MM+ segments!)