datomic 2024-02-12 | Slack Archive

Hi, when starting datomic transactor with healthcheck, I'm getting

java.lang.RuntimeException: Unable to start ping endpoint 0.0.0.0:8080
Terminating process - Error starting transactor
...
Caused by: java.lang.IllegalStateException: Insufficient configured threads: required=3 < max=3 for QueuedThreadPool[qtp1139691800]@43ee5118{STARTED,3<=3<=3,i=3,r=-1,q=0}[ReservedThreadExecutor@4bc6d1c7{reserved=0/1,pending=0}]

bin/transactor -Xmx4g -Xms4g config/mytransactor.properties Where config is typical postgresql one, with the difference health endpoint is set to 8080 (`ping-host=0.0.0.0` ping-port=8080) And I have this also: memory-index-threshold=32m memory-index-max=256m object-cache-max=128m

Ivar Refsdal19:02:46

Can you try adding:

ping-concurrency=6

to config/mytransactor.properties and see if that helps? IIRC I found that setting on some forum

jaret23:02:00

Howdy all! We just released https://forum.datomic.com/t/datomic-local-1-0-277-now-available/2378, client-cloud 1.0.125, client-pro 1.0.78 with a fix for uri deserialization. I've updated the 2 ask.datomic posts (https://ask.datomic.com/index.php/870/import-cloud-not-compatible-with-db-type-uri?show=870#q870, https://ask.datomic.com/index.php/943/why-values-type-uri-return-com-cognitect-transit-impl-uriimpl?show=943#q943) where issues were reported but wanted to share a note here. Cheers everyone!

👍 6

🎉 6

cch119:02:29

Two steps forward, one step back: my automated ion deploys started failing due to a new (unexpected) dependency conflict.

cch119:02:44

@U1QJACBUM, I know it's not a high priority, but the whiplash from "ignore this dependency conflict" and "don't ignore that conflict" makes it nearly impossible to automate a deploy process around ions.

jaret22:02:42

Is it the client cloud version with what is on the computer nodes? What was the conflict this time?

jaret22:02:00

We simply don’t cut a new Datomic Cloud version every time we cut client and that’s a conflict that is reported when they mismatch. I don’t think we should cut a new cloud every time, but we should make the conflict checking work

cch122:02:33

Here are the reported conflicts since the update:

[com.datomic/client-impl-shared {:mvn/version "1.0.100"}]
[com.datomic/client-cloud {:mvn/version "1.0.124"}]

cch122:02:06

Maybe not report conflicts on patch versions of com.datomc... stuff? Implicitly asserting that forwards compatibility is guaranteed for such conflicts?

👍 1

cch122:02:46

I appreciate that having to update DC every time is a huge hassle that will push the pipeline further out.

cch122:02:22

But it does put the burden on the user to either (a) adopt the new version, accept the conflict and assume code written against the new version is compatible with the version running in the Ion or (b) defer the update until DC catches up.

jaret22:02:58

In total agreement with your points

cch122:02:03

BTW, is there any "meat" on the belief that patch version mismatches are "safe" on com.datomic stuff? Or is that case-by-case caveat emptor? If there is meat, then suppressing the conflict warning seems like a great compromise.

cch115:02:50

@U1QJACBUM, it would also be nice to see the conflicts without actually trying a deploy. Perhaps a "dry-run" switch.

jaret15:02:32

I mean right now its checking against a manifest from Cloud. I imagine there is a way we could have that published without even needing to hit the system. This is a good idea! Let you pre-assess if the conflicts are important to you. Regarding "Meat" The only meat there is if we add a new api or break an old one (obviously not the goal). But knowing which version you have matters in those situations even though they are extremely rare in Datomic land.

2024-02-12

Channels