Fork me on GitHub
#xtdb
<
2021-06-01
>
valerauko09:06:45

Just wondering, what Java versions is Crux tested against?

jarohen09:06:36

currently just Java 8, as our minimum requirement, and we also have a number of projects using the Java 11 LTS I don't think we have much using Java 16 yet though - there's been enough added/changed in recent versions that we should also explicitly test against those too

valerauko09:06:25

no rush really as clojure doesn't officially support any of those yet. but 17 (coming this fall) is going to be an lts which clojure is gonna support, and considering the significant amount of changes (especially wrt illegal access) it might be a good idea to look at it early

đź’Ż 6
jarohen09:06:03

agreed, yep 🙂

valerauko09:06:50

I tried using it with the LMDB backend and it doesn't work on JDK 16 or 17. CPU usage on one core goes to 100% and stays there, and the put/entity-history/entity workflow from the tutorial doesn't work (entity/entity-history return empty vector or nil)

jarohen10:06:27

This now seems related to the issue raised in https://clojurians.slack.com/archives/CG3AM2F7V/p1622229438062400?thread_ts=1622226996.061800&amp;cid=CG3AM2F7V - would you mind retrying this against the dev-SNAPSHOT version?

seancorfield15:06:30

@U050V1N74 That’s just a short-term workaround, right? I thought all those “add-opens” and similar existed just to help people migrate from Java 8 and were going away at some point?

seancorfield15:06:11

(I know the --illegal-access flag changed in 16 and is going away in 17)

jarohen15:06:43

@U04V70XH6 semi-permanent until we can find something better, I'm afraid - we're using it (as I understand it) because ConcurrentHashMap doesn't ever downsize its internal data structures, which causes us issues when we're using it as a cache - it degrades to a scan of a large empty array

jarohen15:06:33

our fallback without it is to use an LRU cache instead, which performs well but not quite as well as the newer second-chance cache - so we have options, thankfully

markaddleman23:06:12

I'd like to conditionally write a new document only if some special value in the document matches what's already in the database (I'm trying to ensure that the client has the most recent data before committing a document update). My intent is to write a transaction function that throws an exception if the values don't match. How can I check if the transaction failed due to the exception? As near as I can tell, the result of submit-tx doesn't distinguish between success and failure.

markaddleman14:06:32

Thanks. I had forgotten that submit-tx kicks off async activity and my app has to await-tx and then tx-committed?