Fork me on GitHub
#datomic
<
2023-02-21
>
chrisetheridge15:02:33

has anyone ever encountered an exception like this?

org.apache.activemq.artemis.api.core.ActiveMQIllegalStateException: AMQ229025: Cannot delete queue admin.response63f4e22b-baa4-46a1-aef9-5c90a328a87e on binding admin.response63f4e22b-baa4-46a1-aef9-5c90a328a87e - it has consumers = org.apache.activemq.artemis.core.postoffice.impl.LocalQueueBinding
this started happening when i switched to JDK 17. i switched back to 11, and the issue still occurs

chrisetheridge16:02:46

okay seems to be something to do with JDK 17. removing it fixes the problem

ghadi16:02:25

IIRC check the release notes on recent releases

chrisetheridge16:02:30

ah, this was PICNIC 😄 my local transactor version was out of date

Clément Ronzon19:02:46

Hi, When I perform a transact I get this in the response:

:db-before {:database-id "a4b39280-19a4-4362-9e6b-8b45b31b64fc",
             :db-name "my-db",
             :t 11967,
             :next-t 11968,
             :type :datomic.client/db},
 :db-after {:database-id "a4b39280-19a4-4362-9e6b-8b45b31b64fc",
            :db-name "my-db",
            :t 11968,
            :next-t 11969,
            :type :datomic.client/db}
Is it possible to “rollback” the db to it’s :db-before state somehow? I have limited experience with Datomic Cloud.

favila19:02:13

strictly speaking, no, because the datomic is accumulate-only, append-only. You will always at least have a record that the transaction happened, and you cannot remove that.

favila19:02:17

But the :tx-data field of that response is the datoms added to the database in that transaction. You can invert their op (add -> retract, retract->add), filter out the db/txInstant datom, and issue a new transaction which “undoes” what happened in that tx. Assuming no other changes happened in the meantime, your “now” unfiltered, non-history db will now look like it did at db-before, except the tx of the datoms that are part of the undo transaction will not be exactly the same.

favila22:02:38

Should we expect query io-context and query-stats to be returned by client-api calls to peer-server? I don’t seem to get a :ret, however I do get complaints about unqualified io-context keywords Execution error (ExceptionInfo) at datomic.client.api.async/ares (async.clj:58). io-context must be a qualified keyword, which shows that something in the stack knows about it. I’m using client 1.0.75 with datomic peer server 1.0.6610.

Joe Lane00:02:38

You using d/q or d/qseq?

Joe Lane01:02:23

Hmm. I’ll ping the team tomorrow to double check what’s going on. Can you send in the full deps graph?

Joe Lane01:02:50

Is that the latest client pro? (Forgive me, I can’t remember)

favila01:02:00

I’m guessing from your response that it is expected to return io-stats and query-stats?

favila01:02:19

AFAIK it is the latest, it’s what’s in the docs

Joe Lane01:02:08

I’ll have to double check but I’d be surprised if it wasn’t.

Keith14:02:21

Odd, if I run peer-server from the distribution available on http://my.datomic.com for 1.0.6610, I can request and receive query-stats.

➜  datomic-pro-1.0.6610 bin/run -m datomic.peer-server -h localhost -p 8998 -a myaccesskey,mysecret -d hello,datomic:
Serving hello
➜  datomic-pro-1.0.6610 bin/repl
Clojure 1.11.1
user=> (require '[datomic.client.api :as d])
nil
user=> (def client (d/client {:server-type        :peer-server
                        :access-key         "myaccesskey"
                        :secret             "mysecret"
                        :endpoint           "127.0.0.1:8998"
                        :validate-hostnames false}))
#'user/client
user=> (def conn (d/connect client {:db-name "hello"}))
#'user/conn
user=> (def db (d/db conn))
#'user/db
user=> (d/q {:query '[:find ?ident :where [1 :db/ident ?ident]]
       :args [db]
       :query-stats true})
{:ret [[:db/add]], :query-stats {:query [:find ?ident :where [1 :db/ident ?ident]], :phases [{:sched (([1 :db/ident ?ident])), :clauses [{:clause [1 :db/ident ?ident], :rows-in 0, :rows-out 1, :binds-in (), :binds-out [?ident], :expansion 1}]}]}}

favila14:02:25

I have a hunch it’s the com.datomic/client-api version

favila14:02:57

Here are the dependencies of just client-pro 1.0.75 plus clojure 1.11.1 as reported by deps.edn

com.datomic/client-pro 1.0.75
  . com.cognitect/anomalies 0.1.12
  . com.datomic/client 1.0.126
    . com.cognitect/anomalies 0.1.12
    . com.datomic/client-api 1.0.58
      . org.clojure/core.async 1.5.648
    . com.datomic/client-impl-shared 1.0.98
    . com.datomic/query-support 0.8.28
    . com.cognitect/http-client 1.0.111
      . org.clojure/core.async 1.5.648
      . org.eclipse.jetty/jetty-client 9.4.44.v20210927
        . org.eclipse.jetty/jetty-http 9.4.44.v20210927
        . org.eclipse.jetty/jetty-io 9.4.44.v20210927
          . org.eclipse.jetty/jetty-util 9.4.44.v20210927
      . org.eclipse.jetty/jetty-http 9.4.44.v20210927
        . org.eclipse.jetty/jetty-util 9.4.44.v20210927
        . org.eclipse.jetty/jetty-io 9.4.44.v20210927
      . org.eclipse.jetty/jetty-util 9.4.44.v20210927
    . org.clojure/core.async 1.5.648
  . com.datomic/client-impl-shared 1.0.98
    . com.cognitect/anomalies 0.1.12
    . com.cognitect/hmac-authn 0.1.210
      . commons-codec/commons-codec 1.15
      . com.cognitect/anomalies 0.1.12
      . org.clojure/core.async 1.5.648
    . com.cognitect/http-client 1.0.111
    . com.cognitect/transit-clj 1.0.329
      . com.cognitect/transit-java 1.0.362
        . com.fasterxml.jackson.core/jackson-core 2.8.7
        . org.msgpack/msgpack 0.6.12
          . com.googlecode.json-simple/json-simple 1.1.1
          . org.javassist/javassist 3.18.1-GA
        . javax.xml.bind/jaxb-api 2.3.0
    . org.clojure/core.async 1.5.648
  . org.clojure/core.async 1.5.648
    . org.clojure/tools.analyzer.jvm 1.2.2
      . org.clojure/tools.analyzer 1.1.0
      . org.clojure/core.memoize 1.0.253
        . org.clojure/core.cache 1.0.225
          . org.clojure/data.priority-map 1.1.0
      . org.ow2.asm/asm 9.2
      . org.clojure/tools.reader 1.3.6

favila14:02:03

this does not report io-stats or query-stats

favila14:02:42

The libs packaged into datomic-pro-1.0.6610.zip are higher:

favila14:02:13

client-pro-1.0.75.jar # the same
client-1.0.127.jar    # vs 1.0.126. NOT ON MAVEN CENTRAL, but it has 1.0.130
client-api-1.0.65.jar # vs 1.0.58. NOT ON MAVEN CENTRAL, which only goes to 1.0.62
client-impl-shared-1.0.99.jar # vs 1.0.98

favila14:02:04

overriding to client-1.0.130 doesn’t fix it, but that still depends on client-api-1.0.62

favila14:02:27

I haven’t tried every combo, but in any case it looks impossible to get the same versions via maven as via datomic-pro

favila16:02:16

I’m going to file a support ticket

favila16:02:15

number 3805

👍 2