Hi juxt team. Do you have a timeline for a 1.0 release?

Hi @emil0r we are soon launching our official beta program to go out of alpha. As part of this we are looking to invite people/companies to try out Crux and give us their feedback.

There is an impending change coming first to the API - just the way you configure/start-up Crux nodes - we need to merge, test, and publish this first

so we are giving 🙂 need to tackle that multi-crux approach in one VM... or is it only my computer behaving weirdly?

@olekss.janis We tested and can't see a problem ourselves, but that's not to mean there isnt a problem somewhere. @ognivo might have a go with your gradle.tks to see if he can reproduce

It MIGHT be something with my computer, might be I will try the code on different computer later...

@jonpither but you most likely were testing using Clojure? It might be that using clojure, it somehow precompiles everything before start, and then does not have problems> I am invoking crux from kotlin -> and obviously then clojure runtime does compilation of functions during class loadtime or something... and that gets some strange clashes on classpath

yes my test was via Clojure. We'll try and test your setup

whole kotlin project

thanks @olekss.janis

@jonpither but there is question, is crux even designed to run several instances in the same VM? Might be I am simply breaking/asking some contract which was never promised in the first place and it is "limitation" of crux?

and then it is our problem to work around it

@olekss.janis ithere is no fundamental issue I'm aware of with running multiple nodes on the same VM. As long as you configure different directories for the K/V store and event log. That said, it hasn't been exhaustively tested, so I can't be 100% sure there isn't an issue.

I think if there is the issue, then it is not explicit crux problem, but something to do with me not understanding fully how embedded clojure behaves in such cases during runtime

if you have the bandwidth, you could try using a h2 database and the JDBC setup, just to poke Crux in a different way

that was my backup plan, but looks like problem arises on some sub-component compilation, as I understand the clojure app can have .clj files inside without .class files, and when clojure starts working it compiles the functions during runtime... and it clashes on that... I don't think it's problem on DB -> I actually tried to use the rockdb or what was it's name... same result

could you AOT beforehand? - Require a bunch of namespaces

in theory I could, but will it dive inside crux dependencies... as all the breakages was on taonesso -> will clojure plugin find that? I doubt?

Could you show the error stack here?

hmmm it always is random -> will try to produce one

and don't try to find syntax error actually, it will be something similar in different places -> sometimes vars are not being found or something... it really looks like random race condition

nice one @ognivo

Here I will paste build snippet which has needed stuff to get clojure inside kotlin project

this has this clojure build task with aotAll enabled, and it does look inside the sourcepath and compiles .clj files, but will it help going inside transitive .jars -> I doubt

yep, we will try AoT'ing first

ok I guess now you have everything to tackle the problem -> ability to repeat the problem and see if it's even fixable

the usecase in real life is that we have integrationTests running on pipelines, and those tests spin up several Corda nodes, which each has the service with the crux inside, and because integrationTest runner runs in one VM, getting this problem...

thanks @olekss.janis we will look into it - and we will raise an issue also

@olekss.janis hey. Thanks again for raising the issue and providing a full example project, that was really helpful! A PR with a fix is on its way here https://github.com/juxt/crux/pull/353

Ohh guys, if you can fix this in a day... that is so awesome. So I suppose at the end it will be some sort of version bump-up which I will change in my end, and then we get to the next bug 🙂

@olekss.janis yeaahh ::)) how do you envision your final topology with Crux? RocksDB index and Kafka storage? Or jdbc store? Or you want stay with memdb ?

naah, we are in the first step -> crux indexing into, most likely some DB, as during runtime there will be usual DB, so would be normal to use it also for indexing

in real production case we won't have the race conditions, as there will be 1:1 between node and crux... We need crux to have that attribute based queries

in first phases it will be something out of box -> RocksDB I suppose

also we want to minimize dependencies, so that final deployment is not overblown

and thanks for reacting and trying to fix the bug 🙂 I appreciate it greately...

Cool! So yeah, I’ll try RocksDB from Kotlin then 🙂 @olekss.janis