This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-17
Channels
- # arachne (1)
- # beginners (42)
- # boot (4)
- # cider (28)
- # clara (9)
- # cljs-dev (149)
- # cljsrn (5)
- # clojure (185)
- # clojure-austin (2)
- # clojure-dusseldorf (4)
- # clojure-italy (14)
- # clojure-norway (1)
- # clojure-russia (18)
- # clojure-spec (35)
- # clojure-uk (36)
- # clojurescript (78)
- # core-async (6)
- # data-science (20)
- # datomic (48)
- # emacs (1)
- # fulcro (2)
- # garden (4)
- # hoplon (47)
- # jobs (5)
- # jobs-rus (1)
- # leiningen (2)
- # lumo (12)
- # off-topic (8)
- # om (8)
- # onyx (39)
- # parinfer (19)
- # re-frame (100)
- # reagent (15)
- # ring-swagger (1)
- # sql (8)
- # vim (1)
- # yada (20)
is it possible to delete a memory db? it looks like its still retained somewhere in the heap, even after d/release
and d/delete-database
@matthavener Wouldn't its lifecycle on the heap be determined by GC?
that’s what I was hoping, but it doesn’t seem to be the case 😞
if I transact 1 mil datoms, call ‘d/delete-database’ and ‘d/release’, and then dump the heap, I see 1 mil datomic.db.Datum instances, even after a manual GC
so eventually, after repeating that pattern, my JVM runs out of memory
I'm guessing "manual GC" means (System/gc)
? Have you confirmed that GC is actually being run (e.g. via jstat
)?
I realize this isn't particularly helpful, but it might provide some useful data points. Could certainly just be that they said, "This is a dev tool. We're not going to worry about running out of memory." But only a rep could answer that.
yeah, we’re abusing the mem db for a kind of whacky kafka+datomic CQRS-type thing
I will check GC with jstat though, good idea
Is the use-case of running a Peer in AWS Lambda JVM runtime still in the status of “we don’t expect that to work and offer no advice or support”?
I believe the the Client API is the way to go in regards to running Datomic + Lambda. Peers will be off-loaded to old-school EC2 as usual
That certainly seems reasonable, however what I was hoping to do was run a Vase service in Lambda and it uses the Peer library. I get as far as it refusing to launch because the transactor keystore and truststore are not at the literal file URIs starting with /datomic
that the library expects
I guess my hobby project is going to be more involved than I had thought. 😄
@matthavener are you sure you don't have a reference to the connection somewhere? a def
or a *1
or something?
favila: yeah, a bit more digging and I think that is the issue
mem db connections probably have strong references to their data, whereas normal connections have some indirection
trying to track down a transaction that includes many retractions on a new db that doesn't contain many transactions. not sure how to form the query without performing a full scan. tried with:
(datomic/q
'[:find (count ?e)
:in $ ?log
:where
[?e ?a ?v ?tx false]
[(tx-data ?log ?tx) [[?e ?a ?v _ ?op]]]]
(datomic/history (latest-db))
(datomic/log (conn)))
even if i could filter down to transactions that contain 10 or more datoms i would quicky find itjust tried fully excising 923 entities. doesn't appear to take effect as i assume it's going to async reindex at some point
ah, missed that. apparently sync-excise
too. though i don't understand how sync-excise
could not communicate w/ transactor
but the index roots are definitely pulled directly from storage; maybe transactor also informs (via a push) peers that storage is updated
i'm seeing some weird behavior in my code. I have code wrapped up in a try with (catch Exception e)
but it doesn't seem to be catching db.error/transactor-unavailable clojure.lang.ExceptionInfo exceptions