This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-25
Channels
- # aleph (2)
- # announcements (7)
- # babashka (6)
- # beginners (53)
- # calva (17)
- # cider (5)
- # clj-kondo (137)
- # cljs-dev (19)
- # cljsrn (14)
- # clojure (74)
- # clojure-conj (9)
- # clojure-europe (13)
- # clojure-houston (1)
- # clojure-italy (16)
- # clojure-nl (21)
- # clojure-spec (3)
- # clojure-uk (9)
- # clojuredesign-podcast (24)
- # clojurescript (85)
- # cursive (11)
- # datomic (28)
- # duct (3)
- # emacs (6)
- # figwheel-main (1)
- # fulcro (68)
- # graalvm (19)
- # graphql (3)
- # joker (32)
- # kaocha (10)
- # lambdaisland (1)
- # malli (50)
- # off-topic (13)
- # other-languages (7)
- # pathom (2)
- # pedestal (14)
- # re-frame (53)
- # reitit (8)
- # shadow-cljs (57)
- # specter (2)
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
https://forum.datomic.com/t/unable-to-connect-to-transactor-from-to-ec2-instances/568/2
@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: https://docs.datomic.com/on-prem/aws.html So, yes, connection from peers to transactor is secured via randomly generated credentials, and it’s ok to open transactor to the public.
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.
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",...
Yup:
"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": [
"com.amazonaws.http.AmazonHttpClient$RequestExecutor",
"handleRetryableException",
"AmazonHttpClient.java",
1175
]
},
{
"Type": ".SocketException",
"Message": "Too many open files",
"At": [
".Socket",
"createImpl",
"Socket.java",
460
]
}
This was with 480-8770. We've since upgraded to 535-8812 and haven't seen it sinceSeeing 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": [
"com.amazonaws.http.AmazonHttpClient$RequestExecutor",
"handleRetryableException",
"AmazonHttpClient.java",
1175
]
},
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?
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.