Fork me on GitHub

We just had an alarm from our datomic transactor AlarmLogWriteTimedOut however I can't seem to find from google searches out what would causes this alarm. All I have been able to find is which says to contact datomic support. I thought I would ask here incase other had seen this and to potentially share the knowledge once we find out what causes this.


@karlmikko I’d definitely log a case to support, especially if you’re still seeing errors. But generally that alarm indicates the transactor timed out waiting for storage to acknowledge a write, specifically to the transaction log.


thanks @U1QJACBUM - I will lodge a cast today - the thing i was a bit confused about was the term log as it could be the log file on disc or the transaction log.


I managed to find the exception thrown in the logs and it was a timeout talking to dynamodb, and looking at dynamodb metrics at the time there was not failures and plenty of read/write capactity.


As an update to the issue reported yesterday with t2 instances. We resolved the issue by working with AWS last night.


I keep running into problems where library code trying to determine whether to use the Peer or Client API gets it wrong. See My question here is, is there a well defined way to determine which API the code is using? Followup question: Are more people using the Peer or the Client? The Datomic Cloud seems to require the Client but are there a lot of people also using the Peer?


Hi @U050VTWMB, I found an issue that may be related in the onyx-kafka plugin. The modern Datomic Pro (peer lib) includes namespace datomic.client where I don't believe it used to. see -- you may be able to make use of the :exclusions workaround


I fixed the auto-detection mechanism for onyx-datomic -- perhaps a similar fix is needed in one of the libraries you're consuming.


could be useful to run leim pom && mvn dependency:tree -Dverbose=true, should show you if anything besides datomic-pro is pulling in the client lib dependency.


many thanks


Another question: datomic.client.api/index-range seems to support a :limit and :offset arguments but it looks like they are ignored. Is that the case or is there a good example of them being used? See