Fork me on GitHub

Couldn’t sign up for Datomic Forum (seems like it’s getting troubles lately), maybe somebody here knows: is it safe to open transactor port to the public, assuming it’s connected to a password-secured SQL storage? I understand that peers first connect to the storage, then get transactor coordinates and connect to it, but couldn’t find the authorization mechanism between peer and transactor in the docs.


peers communicate with transactor via an encrypted channel so it’s OK to host transactor on public IP. In fact, this is the only config that worked for us


@U0FHWANJK thanks, at some point we had the same error, but setting host to internal network IP (inside VPC) made it to work. That’s good to know that the connection between peer and transactor is secure, but my concern is different: I wonder whether somebody else could actually transact / read something via the open transactor port, which is why I’m interested in the auth protocol (handshake?) between peer and transactor.


somewhat sure all communication into transactor requires the “secret” value which is stored in backed storage


Ugh, it’s actually in the docs: So, yes, connection from peers to transactor is secured via randomly generated credentials, and it’s ok to open transactor to the public.


still felt a bit exposed to me too


We’ve currently secured transactor via firewall to allow only connections from the exact peer, but that’s kinda inconvenient for dev (requires ssh tunnelling) and autoscaling (requires to manage all the internal network IPs of our peers).


Hi, I’m new to Datomic. Is there any advice or best practice if I’d like to connect Datomic in ClojureScript/Nodejs? Thanks.


cloud or on-prem? There are no official peer libraries for cljs or node


Right now using on-prem. But will use cloud in production. Yes. I can’t find cljs library.


@jaret I know I asked you about whether or not PollingCacheUpdateFailed errors had been addressed recently, but I may have been overly distracted when you answered. (To refresh your memory: What we're seeing is part of our Datomic Cloud system stopping (a periodic CloudWatch Event that writes out to a Vertica database) while the rest of the system keeps humming along fine. I've seen PollingCacheUpdateFailed errors in the Cloudwatch logs that correlate with this.)


@grzm looks like… :

"Msg": "PollingCacheUpdateFailed",
    "Cache": "CatalogCache",
    "Err": {
        "CognitectAnomaliesCategory": "CognitectAnomaliesFault",...


What version of Datomic Cloud are you running on this system?



"Msg": "PollingCacheUpdateFailed",
    "Cache": "cache-group-poller",
    "Err": {
        "CognitectAnomaliesCategory": "CognitectAnomaliesFault",
        "DatomicAnomaliesException": {
            "Via": [
                    "Type": "com.amazonaws.SdkClientException",
                    "Message": "Unable to execute HTTP request: Too many open files",
                    "At": [
                    "Type": ".SocketException",
                    "Message": "Too many open files",
                    "At": [
This was with 480-8770. We've since upgraded to 535-8812 and haven't seen it since


Seeing that in various caches: index-group-poller, tx-group-poller, cache-group-poller, query-group-poller, autoscaling-group-poller. Looks like they generally happen in pairs or three at a time, mix-and-matching which cache groups are included.


One that happens on its own is CatalogCache , with

                        "Type": "com.amazonaws.SdkClientException",
                        "Message": "Unable to execute HTTP request: Connect to  [] failed: Read timed out",
                        "At": [


So one of the causes of that error (pollingCacheUpdateFailed) was addressed and other causes as long as they are transient shouldn’t represent a problem. Re: the CloudWatch Event that writes to the Vertica DB are you seeing any other errors or any other correlations? are you deploying at the same time? is the event special in any way?


I’d be happy to poke at the metrics and logs if you want to give me read-only access.


Haven't seen other errors at the same time, which is why it's kinda been stumping us. No deploys either: it happens after the system's been running for at least a couple of days running fine. Just stops writing. Let me coordinate with the client and get back to you on the log access: that'll likely have to wait until tomorrow.


And you have to kick over the application or datomic to get it back up again? @grzm?


We "redeploy" (same revision) and it all starts working again. (what would it mean to restart only Datomic?)


Has there been any news on the xray daemon for datomic compute nodes?


@tyler it is included on the nodes in the latest release


but it’s up to you to configure/use it for now


more docs/info coming in the future


👍 awesome, we’re happy to configure it just need that daemon running. Thanks.