Fork me on GitHub
#datomic
<
2018-05-14
>
Ethan Miller00:05:09

Anyone run into this error when trying to connect to a datomic cloud stack: > 2018-05-13 20:36:01.593:WARN:oejuc.AbstractLifeCycle:nREPL-worker-1: FAILED SslContextFactory@56f447c4(null,null): java.lang.IllegalStateException: SSL doesn't have a valid keystore> > java.lang.IllegalStateException: SSL doesn't have a valid keystore`

Ethan Miller01:05:34

It occurs for me when running

(require '[datomic.client.api :as d])
(def cfg {:server-type :cloud
          :region "us-east-2"
          :system "<sysname>"
          :query-group "<sysname>"
          :endpoint ".<sysname>."
          :proxy-port 8182})
(def client (d/client cfg))

Ethan Miller01:05:47

Before that, I was also getting a bunch of what seemed to be dependency conflict related errors, so my project.clj has some exclusions:

[com.datomic/client-cloud "0.8.50"
                  :exclusions [org.eclipse.jetty/jetty-io
                               ;; org.eclipse.jetty/jetty-client
                               org.eclipse.jetty/jetty-util
                               ;; org.eclipse.jetty/jetty-http
                               commons-logging
                               commons-codec]]

joshkh12:05:58

to follow up with my async question from yesterday, i've noticed something interesting using datomic.client.api. after transacting in repl1 i'm left with {:db-after {:t 765 }}. then, in repl2, no matter how many times i try to fetch the latest db using d/db, it always returns {:t 764}, one t value behind. it stays this way forever until i attempt to query for some data. the query doesn't run returning anything as the time is one transaction behind, however the action of querying does update the db value to have {:t 765}. In REPL 1:

(do-some-transaction)
=> {:db-before
          {:database-id "some-db-id", :db-name "my-test-db", :t 764, :next-t 765, :history false, :type :datomic.client/db},
 :db-after
          {:database-id "some-db-id", :db-name "my-test-db", :t 765, :next-t 766, :history false, :type :datomic.client/db},
 :tx-data
          [#datom[13194139534077 50 #inst "2018-05-14T12:19:52.484-00:00" 13194139534077 true]
           #datom[7868105208367458 73 "SomeData" 13194139534077 true]
           #datom[7868105208367458 70 #uuid "66026046-ef8e-4605-9280-94cbf4c0cd5b" 13194139534077 true]],
 :tempids {}}
In REPL 2:
; Always 764 no matter how many times i re-run this:
(d/db @conn)
=> {:t 764, :next-t 765, :db-name "my-test-db, :database-id "some-other-id", :type :datomic.client/db}
In REPL2 again:
; To update the time, run any query:
(d/q '[:find (pull ?person [*])
                     :in $ ?person-name
                     :where
                     [?person :person/first-name ?person-name]]
                   (d/db @conn)
                   "person-from-previous-transaction"
                   )
=> []
(d/db @conn)
; time has been updated
=> {:t 765, :next-t 766, :db-name "my-test-db", :database-id "some-other-id", :type :datomic.client/db}
shouldn't (d/db conn) always return the oldest version of the database?

souenzzo13:05:44

(d/db conn): An available db (any) @(d/sync conn): Ask the transactor the last available db and wait for it. @(d/sync conn t): Wait for a db with basis-t >= t

favila13:05:02

Client api is not push like the peer api

😢 4
joshkh13:05:52

exactly. i'm pretty stumped about the "right" thing to do here.

favila13:05:16

Use peer api?

favila13:05:06

I know cognitect is pushing cloud and client api very hard, but as of now it is much more impoverished

joshkh13:05:08

is the peer api compatible with cloud?

favila14:05:08

cloud only supports client

joshkh12:05:07

where as yesterday's discussion lead me to think it was latency between two clients, this is telling that i need to actively take action to tell the second client that someone else has updated the db. obviously running a bogus query isn't the right way to do that...

👍 4
favila13:05:38

I don’t know how this works with the client api. Peers are actively pushed new transaction records by the transactor. Clients don’t have transactions pushed to them.

favila13:05:08

Syncing may not be possible with the client api

souenzzo13:05:44
replied to a thread:to follow up with my async question from yesterday, i've noticed something interesting using `datomic.client.api`. after transacting in repl1 i'm left with `{:db-after {:t 765 }}`. then, in repl2, no matter how many times i try to fetch the latest db using `d/db`, it _always_ returns `{:t 764}`, one t value behind. it stays this way forever until i attempt to query for some data. the query doesn't run returning anything as the time is one transaction behind, however the action of querying _does_ update the db value to have `{:t 765}`. In REPL 1: (do-some-transaction) =&gt; {:db-before {:database-id "some-db-id", :db-name "my-test-db", :t 764, :next-t 765, :history false, :type :datomic.client/db}, :db-after {:database-id "some-db-id", :db-name "my-test-db", :t 765, :next-t 766, :history false, :type :datomic.client/db}, :tx-data [#datom[13194139534077 50 #inst "2018-05-14T12:19:52.484-00:00" 13194139534077 true] #datom[7868105208367458 73 "SomeData" 13194139534077 true] #datom[7868105208367458 70 #uuid "66026046-ef8e-4605-9280-94cbf4c0cd5b" 13194139534077 true]], :tempids {}} In REPL 2: ; Always 764 no matter how many times i re-run this: (d/db @conn) =&gt; {:t 764, :next-t 765, :db-name "my-test-db, :database-id "some-other-id", :type :datomic.client/db} In REPL2 again: ; To update the time, run any query: (d/q '[:find (pull ?person [*]) :in $ ?person-name :where [?person :person/first-name ?person-name]] (d/db @conn) "person-from-previous-transaction" ) =&gt; [] (d/db @conn) ; time has been updated =&gt; {:t 765, :next-t 766, :db-name "my-test-db", :database-id "some-other-id", :type :datomic.client/db} shouldn't (d/db conn) always return the oldest version of the database?

(d/db conn): An available db (any) @(d/sync conn): Ask the transactor the last available db and wait for it. @(d/sync conn t): Wait for a db with basis-t >= t

joshkh13:05:34

ah yes, i saw that yesterday (thanks!) but i don't think sync is available in the client api

Ethan Miller13:05:18

If anyone has any thoughts on this trouble I'm having migrating to datomic cloud, I'd be much obliged: https://stackoverflow.com/questions/50331264/ssl-doesnt-have-a-valid-keystore-error-when-trying-to-connect-to-datomic-clou

joshkh13:05:10

sounds like you need an :exclusion somewhere

souenzzo13:05:10

Oh. There is no sync on client. 😕 Maybe you can do something like: >> POST /auth-me << token: my-token, t: 255 >> GET /my-data?token=my-token&t=255 << 102: please wait .... >> GET /my-data?token=my-token&t=255 << 200: you-data

joshkh13:05:18

i thought about returning the t value but i can't see a way to pass it into the datomic client library

souenzzo13:05:16

you can check:

(let [{:keys [token t]} request
      db (d/db conn)
      current-t (:t db)]
  (if (>= current-t t)
    (do-stuff db token)
    {:status 102}))

souenzzo13:05:42

P.S. not sure if status 102 is "the correct" http status for this case.

joshkh13:05:10

the problem is actually fairly widespread. i have a repl open, a web app, and an asset server all running with their own client connection passing around a t value after each update sounds like a pretty heavy approach to keeping the clients in sync.

joshkh13:05:08

not that it's a bad suggestion! but i feel like i must be missing something.

souenzzo13:05:30

missing the peer API

joshkh13:05:12

have you tried running lein deps :tree | grep jetty? you might have a dependency conflict.

Ethan Miller13:05:50

@joshkh I have. That's how I came up with the exclusions that I'm using.

Ethan Miller13:05:32

I've tried a great many combinations.

joshkh14:05:15

while surely a huge pain, you could knock out the deps and namespaces until you find the culprit. hopefully the project isn't too large? i also had the same problem and even when using lein deps it wasn't immediately clear which library was causing the problem. i think it ended up being something neo4j related.

joshkh14:05:43

also, one of my deps also had a dependency on datomic so i needed some exclusions there as well.

joshkh14:05:22

old code but i also had a fairly heavy handed exclusion (although i don't think most of them apply): [ring/ring-jetty-adapter org.eclipse.jetty/jetty-client org.eclipse.jetty/jetty-http org.eclipse.jetty/jetty-util]