This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-24
Channels
- # announcements (1)
- # aws (2)
- # beginners (147)
- # boot (19)
- # cider (57)
- # clara (52)
- # cljdoc (18)
- # cljs-dev (14)
- # cljsrn (4)
- # clojure (176)
- # clojure-conj (9)
- # clojure-dev (9)
- # clojure-germany (2)
- # clojure-italy (4)
- # clojure-spec (13)
- # clojure-uk (56)
- # clojurescript (72)
- # code-reviews (11)
- # cursive (17)
- # data-science (1)
- # datomic (52)
- # duct (26)
- # emacs (6)
- # events (9)
- # figwheel (1)
- # figwheel-main (21)
- # fulcro (132)
- # funcool (1)
- # graphql (3)
- # jobs-discuss (42)
- # leiningen (3)
- # luminus (45)
- # mount (10)
- # off-topic (2)
- # re-frame (17)
- # reagent (12)
- # reitit (20)
- # ring-swagger (7)
- # rum (3)
- # shadow-cljs (256)
- # slack-help (15)
- # sql (7)
- # tools-deps (50)
- # uncomplicate (1)
- # yada (9)
Is anyone taking steps to recover the Java logging that Ions throws away by default (eg below WARN
level)? (see: https://docs.datomic.com/cloud/ions/ions-monitoring.html#java-logging)
@robert.mather.rmm not yet but I’m super interested in whatever solutions anyone is using for operations/monitoring of Ions apps.
quick ions question. are code deploys supposed to have zero downtime? i'm seeing the following behaviour: 1. deploy a revision, 2. test the lambda and it fails, 3. wait a little bit, try again, and it works:
; A few seconds after an Ions deploy
$ aws lambda invoke --function-name my-compute-group-testfn /dev/stdout
{
"isBase64Encoded" : false,
"statusCode" : 500,
"headers" : {},
"body" : "java.io.IOException: Premature EOS, presumed disconnect"
}{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
; And then a few more second later
$ aws lambda invoke --function-name my-compute-group-testfn /dev/stdout
{"statusCode":200,"headers":{"Content-Type":"application\/edn"},"body":"(some working result)","isBase64Encoded":true}{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
(although we have only tested with production topology without HA). I can report about full production topology later. But it seems like this only happens on the first request.
also (unrelated) - how might one go about applying ring middleware to functions that have been ionize
d with datomic.ion.lambda.api-gateway/ionize
? for example, i'd like to use ring.middleware.format
.
@steveb8n this is a stackoverflow error in Cider, not on a deployed machine. datomic.ions.cast/initialize-redirect
sends cast/event
, cast/dev
and cast/alert
to somewhere other than Cloudwatch for local development. (https://docs.datomic.com/cloud/ions/ions-monitoring.html#local-workflow)
i think there might be a bug in the ion/get-params
fn. it's dropping the first letter of keys that are defined at the root level:
$ aws ssm put-parameter --name rootlevelparam --type String --value "somevalue"
{
"Version": 1
}
(ion/get-params {:path "/"})
=> {"ootlevelparam" "somevalue"}
speaking of which, should lambdas created via ions have access to SSM by default, presumably as part of their generated role? i'm getting the following error User: arn:aws:sts::accid:assumed-role/my-compute-and-region/someid is not authorized to perform: ssm:GetParametersByPath on resource: arn:aws:ssm:my-region:accid:parameter/location/here/ (Service: AWSSimpleSystemsManagement; Status Code: 400; Error Code: AccessDeniedException; Request ID: some-uuid
Hi. Has anyone come across this error before? Seems to happen if I am transacting using a transaction function.
java.lang.RuntimeException: Reader tag must be a symbol
File "NativeConstructorAccessorImpl.java", in sun.reflect/newInstance0
File "NativeConstructorAccessorImpl.java", line 62, in sun.reflect/newInstance
File "DelegatingConstructorAccessorImpl.java", line 45, in sun.reflect/newInstance
File "Constructor.java", line 423, in java.lang.reflect/newInstance
File "Reflector.java", line 180, in clojure.lang/invokeConstructor
File "form-init513985284846454305.clj", line 1, in user/[fn]
File "error.clj", line 135, in datomic.error/deserialize-exception
File "error.clj", line 117, in datomic.error/deserialize-exception
File "peer.clj", line 399, in datomic.peer.Connection/datomic.peer.Connection
File "connector.clj", line 169, in datomic.connector/[fn]
File "connector.clj", line 167, in datomic.connector/[fn]
File "MultiFn.java", line 233, in clojure.lang/invoke
File "connector.clj", line 194, in datomic.connector/[fn]
File "connector.clj", line 189, in datomic.connector/[fn]
File "connector.clj", line 187, in datomic.connector/[fn]
File "core.clj", line 2022, in clojure.core/[fn]
(f))
File "AFn.java", line 18, in clojure.lang/call
File "FutureTask.java", line 266, in java.util.concurrent/run
File "ThreadPoolExecutor.java", line 1149, in java.util.concurrent/runWorker
File "ThreadPoolExecutor.java", line 624, in java.util.concurrent/run
File "Thread.java", line 748, in java.lang/run
For posterity, it seems the issue was related to using destructuring with namespaced keys. The transaction function had something like
(let [{:person/keys [age name]} data] ,,,)
which gets stored in datomic as
(let[#:person{:keys[age name]} data] ,,,)
changing to
(let [age (:person/age data) name (:person/name data)] ,,,)
was one fix. The root cause was an old version of tools.reader
and/or another dependency. Upgrading dependencies independent of the code change resolves the issue.I see the latest version of client-cloud
is 0.8.66
on Maven (https://search.maven.org/search?q=g:com.datomic%20AND%20a:client-cloud&core=gav), but the Datomic releases page (https://docs.datomic.com/cloud/releases.html#current) says the current release of client-cloud
is 0.8.63
. Which is correct?
@U083D6HK9 the release page is correct. I’ll confirm with the team if we need to update to .66
So I created my first ion to hook up to API gateway, and everything works, except my HTTP response bodies are turning into base-64. Is there an obvious thing I messed up that would cause that?
Nope. As long as you set the binary encoding option in API Gateway to */*
(under Deployment
in the tutorial), you should get a normal response as you'd expect from the outside (eg using Curl). I guess the Gateway does the translation for you, but not from within the testing UI. Everyone seems to run into this! (such as: https://forum.datomic.com/t/base-64-encoded-response-body-in-api-gateway-method-tester/560)
ok, I think my problem was I deployed the API before setting the binary content type. A re-deploy seemed to fix that
Is there any good example of updating a to-many
relationship as one adds objects over time? Suppose I have a datom model
that has a to-many ref rules
. I’ll be adding rules over time, is the solution to this transact a new datom as
(d/transact conn {:tx-data [
{:model/name "name" :model/rules (conj past-rules {:rule/name "new-rule"})
]})
How would it be with :db/add
?
@U09R86PA4 would it be something like [db/add model-id :model/rules rule-id]
?
Yeah, thanks! My conceptual problem was the ability to add a datom to a many-ref
with a single datom on the many side
anyone used this library? https://github.com/RallySoftware/datomic-replication
can I have multiple ion “projects” per compute stack, or am I limited to one? That is, only one resources/datomic/ion-config.edn
? I understand I can split things up into deps, I just want to understand the deployment strategy
also, I frequently get 502 errors on what looks like lambda cold starts (https://forum.datomic.com/t/api-gateway-internal-server-error/678)
We are facing a fascinating problem with Datomic Ions. As our code base grew during the last couple of weeks, deploying to Datomic Ions started failing (CodeDeploy itself gives up and rolls back a previous version to the instance). We initially thought it could be a problem in our setup (we were still on 441) so we updated to 441-8505 but the same behavior kept plaguing us. After spending a considerable amount of time investigating, we found two ways to “solve” the issue but neither seems reasonable enough: 1) Hack Datomic’s EC2 instances and bump the stack size up of the JVM process 2) Keep the code base much simpler than we would need to 🙂
The indication that increasing the stack would work was in the exception that was thrown by starting up datomic.cluster-node
was a a stack overflow one.
I wonder the reasoning behind keeping the stack at 256K. I’m pretty sure @marshall has a superb reason for it.
we’re working on general options all around, but editing the CFT to set the stack size higher is a reasonable option for now
yep, so you’re not going to hit the same memory issues as if you bumped the stack size on a small solo node
I’m not an expert in CF so, what’s the implication of changing it on the CFT? Do we lose this setting when we upgrade the stack in the future?
Yes, it may be that you’ll have to re-set it on upgrade. It depends a bit on what changes in the upgrade