Datomic Knowledgebase - Recent questions tagged peer

Updates to Artemis dependency in Datomic Peer

Tue, 16 Jun 2026 09:36:10 +0000

Hi! Thanks for maintaining Datomic for the community!

I'd like to ask if the Artemis dependency can be updated in Datomic Peer. Currently version org.apache.activemq/artemis-core-client 2.31.2 is used. In the meantime multiple CVEs have been reported and fixed in Artemis. Also, the artefact was relocated from org.apache.activemq » artemis-core-client to org.apache.artemis » artemis-core-client according to MVN (https://mvnrepository.com/artifact/org.apache.activemq/artemis-core-client/2.54.0).

Of course I can do this in deps.edn, but I don't know if that's safe and rather have it changed in Datomic for everybody's benefit:

:deps {com.datomic/peer {:mvn/version "1.0.7622" :exclusions [org.apache.activemq/artemis-core-client]} org.apache.artemis/artemis-core-client {:mvn/version "2.54.0"}}

Thank you for your consideration!

Datomic peer - Support SSO

Fri, 13 Feb 2026 17:36:46 +0000

Datomic currently does not support AWS SSO out-of-the-box

This issue is probably because it uses an old version of dynamodb SDK

I believe that this issue can be fixed by upgrading the AWS SDK to v2

Here a workaround:

https://gist.github.com/souenzzo/42060567479ab2dd916769f1d73042fa

Datomic peer on dynamodb - misleading error message

Fri, 13 Feb 2026 16:19:56 +0000

Starting from a simple setup:

{:deps {com.datomic/peer       {:mvn/version "1.0.7491"}
        org.slf4j/slf4j-simple {:mvn/version "2.0.17"}}}

And trying to connect into a dynamodb connection, it fails with a "s3" error:

user=> (require '[datomic.api :as d])
nil
user=> (d/connect "datomic:ddb://us-east-1/prd/db")
[main] INFO datomic.process-monitor - {:event :metrics/initializing, :metricsCallback clojure.core/identity, :phase :begin, :pid 311, :tid 3}
[main] INFO datomic.process-monitor - {:event :metrics/initializing, :metricsCallback clojure.core/identity, :msec 0.696, :phase :end, :pid 311, :tid 3}
[main] INFO datomic.process-monitor - {:metrics/started clojure.core/identity, :pid 311, :tid 3}
[clojure-agent-send-off-pool-0] INFO datomic.domain - {:event :cache/create, :cache-bytes 502267904, :pid 311, :tid 25}
[clojure-agent-send-off-pool-0] INFO datomic.process-monitor - {:AvailableMB 895.0, :ObjectCacheCount 0, :event :metrics, :pid 311, :tid 25}
Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass (BuiltinClassLoader.java:580).
com.amazonaws.services.s3.model.MultiObjectDeleteException

From this error message, it is pretty hard to find that datomic actually requires an extra dynamodb dependency to work.

https://docs.datomic.com/operation/storage.html#dynamodb-aws-peer-dependency

Possible fixes:

A better error message
Adding this error message to datomic docs, as a "common errors" - do google will be able to find.

"No suitable driver" when starting peer

Fri, 24 Jan 2025 01:10:09 +0000

In the peer container:

root@3249b8857f6f:/opt/datomic# bin/repl
Clojure 1.11.4
user=> (Class/forName "org.postgresql.Driver")
org.postgresql.Driver
user=> (require 'datomic.peer-server)
nil
user=> (datomic.peer-server/-main
"-h" "0.0.0.0"
"-p" "8998"
"-a" "none,none"
"-d" "datomic,datomic:sql://mydb?jdbc=postgresql://catalyst-postgres-1:5432/datomic?user=datomic&password=datomic&jdbc-class=org.postgresql.Driver")
Execution error (SQLException) at java.sql.DriverManager/getDriver (DriverManager.java:299).
No suitable driver
user=>

Long blocking on event `:kv-cluster/get-val` without timeout/retry/failover semantics?

Wed, 23 Jun 2021 09:19:28 +0000

On a test environment, we're seeing this kind of log from the Datomic Peer:

;; ~5 hours CI inactive (if this is relevant)

DEBUG 2021-06-18T13:32:37.702 [clojure-agent-send-off-pool-23]: {:event :kv-cluster/get-val, :val-key "60a4cc9e-ac11-40fe-9bd0-582f8209a403", :phase :begin, :pid 7, :tid 225}

;; 15 minutes pass....

DEBUG 2021-06-18T13:48:25.091 [clojure-agent-send-off-pool-23]: {:event :kv-cluster/get-val, :val-key "60a4cc9e-ac11-40fe-9bd0-582f8209a403", :msec 947000.0, :phase :end, :pid 7, :tid 225}

;; This next one finishes in 21ms:

DEBUG 2021-06-18T13:48:25.094 [clojure-agent-send-off-pool-23]: {:event :kv-cluster/get-val, :val-key "60128f6d-25fb-41f0-a6c2-9c5e73267da7", :phase :begin, :pid 7, :tid 225}
DEBUG 2021-06-18T13:48:25.115 [clojure-agent-send-off-pool-23]: {:event :kv-cluster/get-val, :val-key "60128f6d-25fb-41f0-a6c2-9c5e73267da7", :msec 21.0, :phase :end, :pid 7, :tid 225}

;; and now we start processing the transacts that queued up when the tests started...

INFO  2021-06-18T13:48:25.117 [manifold-execute-43]: {:event :peer/transact, :uuid #uuid "60cca429-7908-49b1-82c8-56b50effb4ce", :phase :start, :pid 7, :tid 282}
DEBUG 2021-06-18T13:48:25.234 [clojure-agent-send-off-pool-24]: {:event :peer/accept-new, :id #uuid "60cca429-7908-49b1-82c8-56b50effb4ce", :phase :begin, :pid 7, :tid 226}
DEBUG 2021-06-18T13:48:25.234 [clojure-agent-send-off-pool-24]: {:event :peer/accept-new, :id #uuid "60cca429-7908-49b1-82c8-56b50effb4ce", :msec 0.462, :phase :end, :pid 7, :tid 226}
INFO  2021-06-18T13:48:25.235 [clojure-agent-send-off-pool-24]: {:event :peer/transact, :uuid #uuid "60cca429-7908-49b1-82c8-56b50effb4ce", :phase :end, :pid 7, :tid 226}

After those 15 minutes of waiting, the peer moved on and transacted all the transactions that happened to queue in the meantime, as if nothing happened. There do not seem to be any interesting or anomalous logs in the Transactor for this time period.

Datomic Peer (1.0.6269) with PostgreSQL storage. The peer and transactor are both running on Kubernetes, but Postgres is hosted outside of the k8s cluster.

I think my followup questions are:

Any idea what could be going on with the :kv-cluster/get-val and how to go about debugging this further?
Is there some timeout we can configure to avoid this kind of situation in a production environment?
Is the probable culprit Kubernetes? If so, has someone seen or fixed similar behavior before?
These logs are happening at the DEBUG level, otherwise we would not even know that the Peer was blocking/hanging/waiting. Are there other metrics or logs we should be monitoring to identify this kind of problem?

What does the memcached/item-too-large log warning mean?

Tue, 27 Oct 2020 17:54:45 +0000

I'm seeing a fair frequency of :memcached/item-too-large statements in my Datomic logs.

Is this a size limitation internal to Datomic? If so, could it mean our system is missing out on some cached segments?

A recent datomic.process-monitor log statement is showing:

{:tid 23,
 :CacheRepair {:lo 1, :count 637, :sum 637, :hi 1},
 :ObjectCacheCount 16634,
 :PeerAcceptNewMsec {:lo 0, :count 348, :sum 1, :hi 1},
 :MemcachedPutSucceededMsec {:lo 0, :count 602, :sum 1276, :hi 177},
 :AvailableMB 5550.0,
 :Memcache {:lo 0, :count 12175, :sum 11537, :hi 1},
 :StorageGetMsec {:lo 2, :count 637, :sum 10089, :hi 831},
 :MemcacheItemTooLarge {:lo 1, :count 4, :sum 4, :hi 1},
 :pid 18,
 :event :metrics,
 :ObjectCache {:lo 0, :count 702668, :sum 690336, :hi 1},
 :MetricsReport {:lo 1, :count 1, :sum 1, :hi 1},
 :PeerFulltextBatch {:lo 1, :count 332, :sum 348, :hi 6},
 :DbAddFulltextMsec {:lo 0, :count 21, :sum 30, :hi 12},
 :MemcachedPutFailedMsec {:lo 0, :count 31, :sum 541, :hi 52},
 :StorageGetBytes {:lo 122, :count 637, :sum 92206399, :hi 31294091}}

Which would seem to suggest a high hit rate judging from the :Memcache :sum / :count

Is this something I can fix or would cause issues?

Thanks!!

Add Cassandra Cluster callback to the Peer

Thu, 22 Oct 2020 17:52:42 +0000

The transactor provides a configurable cassandra cluster callback, but the peers do not. The Cassandra driver depends on old versions of metrics libraries that are incompatible with newer versions used in (for example) clojure metrics. Datastax solution for this requires use of the cluster callback https://docs.datastax.com/en/developer/java-driver/3.5/manual/metrics/#metrics-4-compatibility, but that isn't available in Peers.

Readonly peer access

Thu, 22 Oct 2020 15:30:43 +0000

A peer that can read from the backing store, but not transact