Fork me on GitHub
#datomic
<
2020-04-17
>
kenny14:04:28

We were running an import of data into a Datomic Cloud solo instance and it appears to have crashed. CPU is stuck at 0%. All calls to d/connect results in a Connect Timeout. Is there no health check that can detect and cycle the process/vm in a case like this?

kenny14:04:16

Last log line

{"Gcname":"G1 Old Generation","Gcaction":"end of major GC","Gccause":"Allocation Failure","Msg":"GcEvent","Duration":5584,"Type":"Event","Tid":8,"Timestamp":1587119656023}

kenny14:04:47

I opened a Datomic support request since this is probably too specific.

joshkh16:04:29

i'm interested as well. recently i discovered that one node in my query group had been completely wedged from a bad query, and i only discovered it hours later when a routine code deployment failed due to inefficient memory.

Ben Hammond14:04:54

when I retrieve a db.type/uri datom from datomic cloud using pull it comes back with an unexpected class com.cognitect.transit.impl.URIImpl`. I was sort of hoping for a .URI I know I can manually convert it into a http://java.net.URI using str , my question is whether this is expected behaviour, or whether I have something misconfigured or should I be de-transiting the response from pull

onetom05:04:43

im also using :db.type/uri attrs, but only thru on-prem peers. i would definitely expect it to work on the cloud version too, out of the box. so, my guess is that it's a bug.

Adham Omran19:10:17

Hey @U793EL04V did you ever find an answer to this? I'm facing the same situation at the moment.

Ben Hammond07:10:10

ooh thats quite a while ago. No, I don't think I solved this; I talked myself into eliminating the :db.type/uri datom instead,

Adham Omran07:10:37

I see, thank you for your response. I assume you replaced it with :db.type/String? Was there any other gotcha like this?