Fork me on GitHub
#datomic
<
2018-09-20
>
seantempesta07:09:07

Is anyone else experiencing intermittent Dynamo DB errors? My datomic instance will run for a week or so and then will crash with a message saying Critical failure, cannot continue: Heartbeat failed.

seantempesta07:09:42

Is there a recommended restart protocol to recover from these errors?

stuarthalloway13:09:20

Hi @U06B77GQ6! Are your running in the HA configuration? That will recover automatically.

stuarthalloway13:09:58

Also, make sure your DDB provisioning matches your needs, you can start by looking at https://docs.datomic.com/on-prem/capacity.html#dynamodb.

seantempesta08:09:04

Hi @U072WS7PE! No, I am not using HA. I’m still in alpha testing for my app and we have a tiny amount of traffic and data (the entire database backed up is 336k w/o compression). I’ll take a look at those docs. Maybe we are pushing the defaults?

seantempesta08:09:08

Thanks for the quick response. 🙂

stuarthalloway09:09:23

if you are still early days I would look at Datomic Cloud -- it is less subject to this problem, and your overall AWS cost will almost certainly go down if you use ions.

seantempesta09:09:03

Yeah, I’d like to transition there eventually. It would require rewriting my whole backend though.

seantempesta09:09:05

I haven’t had any stability issues with the dev storage. Would it be a terrible idea to just setup frequent backups to S3 for the time being?

stuarthalloway11:09:27

Probably 😂. I would recommend just turning up the DDB knobs.

seantempesta11:09:36

Will do. Thanks for the advice @U072WS7PE. 🙂

matthavener13:09:45

ah, its an http-only redirect

joshkh17:09:30

how might i go about writing a query to pull all entities?

donaldball17:09:50

(map :e (seq (d/datoms db :eavt))) is a thing you could do

donaldball17:09:44

Probably pour it into a set

joshkh17:09:54

ah, d/datoms! i was just looking at that. thanks.

joshkh17:09:49

in case anyone else needs the same, :eavt needs to be in a map (seq (d/datoms (d/db conn) {:index :eavt}))

joshkh17:09:17

(at least for cloud?)

ho0man13:09:13

thanks nosesmith you are right but I wanted to know aside from go blocks blocking threads, in a system heavily dependent on go blocks should I be concerned about separating critical sections' thread pool from others ?

noisesmith23:09:15

nothing critical should be in a go block

noisesmith23:09:49

the number of threads used for go blocks is small, and doesn't grow, they are a method of coordination, not a utility for execution / parallelism

ho0man16:09:56

Thanks again

ho0man16:09:30

But can you elaborate a little more about "nothing critical should be in a go block" and "they are a method of coordination, not a utility for execution / parallelism"

ho0man16:09:50

Aren't they supposed to be lightweight threads in a sense?

ho0man16:09:30

Your comment kinda scared me, cause quite a few of my applications are actually a network of channels with async/go blocks doing almost all of the work in between them

noisesmith16:09:34

they are for lightweight coordination of state between tasks, anything that uses blocking IO or is CPU intensive should not be in a go block

noisesmith16:09:54

async/thread is OK for blocking IO or CPU intensive tasks

noisesmith16:09:04

it returns a channel that a go block can park on

noisesmith16:09:40

what happens is that when resource-intensive tasks are in go blocks, they can starve the channel operations, since the number of threads for go blocks are limited

ho0man17:09:51

Thanks alot

donaldball17:09:44

interesting, I didn’t realize the api varied thusly

joshkh17:09:21

it also seems to max out at 1,000 values. hmmm...

(count (map #(nth % 3) (seq (d/datoms (d/db conn) {:index :eavt}))))
=> 1000

favila17:09:34

try :limit and :offset in your arg map

joshkh17:09:59

yup, that did it. the api docs refer to the top of the namespace for further docs. is the client open source?

stuarthalloway01:09:42

@joshkh @U09R86PA4 Datomic client is Apache 2 license, license file and source code are present in the .jar

favila01:09:30

ah didn't know that

favila17:09:18

just scroll up

favila17:09:24

no, nothing datomic is open

joshkh17:09:03

ah. there it is. thanks.

favila17:09:16

a query would probably overwhelm the instance, but you could also do [:find ?e :where [?e]]

favila17:09:37

it would dedup for you, but you still have to be able to fit all entity ids in memory

joshkh17:09:50

ExceptionInfo Insufficient binding of db clause: [?e] would cause full scan clojure.core/ex-info (core.clj:4739)

favila17:09:07

well, that's good

favila17:09:17

there's no efficient way to do what you are doing

favila17:09:30

...why are you doing it?

joshkh17:09:54

that's what i'm worried about. basically, all i want is to clone a (cloud) database, and i don't care about history.

joshkh17:09:31

schema migration was the easy part.

favila17:09:18

oh, in this case you do want all datoms

favila17:09:07

This code is on-prem, and also predates mem dbs having history

favila17:09:14

but it may help you get started

favila17:09:51

honestly reading the tx log and transacting each one into a new db is the simplest and safest thing

joshkh17:09:15

fantastic. thanks a lot. 🙂