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`

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))

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]]

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 {}}

; 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}

; 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}

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...

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

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

sounds like you need an :exclusion somewhere

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

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

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}))

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

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.

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

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

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

I've tried a great many combinations.

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.

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

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]