Fork me on GitHub

Is it safe to always set the :server-type to :ion?


i.e. if your app is deployed remotely, the :ion :server-type would connect as a client, and if your app is deployed as an ion, it would use the in-memory client.


@kenny that understanding is correct. The only reason :ion is even a separate thing is the (very) unusual case where you might have one Datomic app be a client to others


is there anything wrong with calling datomic.client.api/connect multiple times?


@U4YGF4NGM connect roundtrips with a server when remote, but that isn't right or wrong without context


I think I asked the wrong question. I’m trying to work around an issue I’m having where if my REPL loads a ns at startup that calls datomic.client.api/client, the REPL hangs


if I defer running the client function until I have a REPL, it loads just fine


I copied the get-client and ensure-dataset functions from the starter repo and was running those in a top-level (def client (get-client)), but I’m moving them into the functions that need them now to avoid hanging my REPL


also I can see it connect successfully in my socks proxy terminal, though it also doesn’t error out if it can’t connect


I have a development k8s cluster deployed in an existing VPC. Because VPC endpoints are only supported in a production tolopology, is my only option for running tests on my k8s cluster that use Datomic to have a production topology system deployed? Seems like an expensive way to run tests when I don't have any HA requirements for tests.


@kenny can you test through the socks proxy & bastion to a solo node?


Some of our tests work that way.


Perhaps. Do you run the socks proxy in the background?


some of our test suites launch the socks proxy from the CLI


That is a blocking script - you'd have to run it in the background somehow. You'd also want to ensure that the socks proxy script connects prior to your tests running.


Barring a local option, which could be run as a test jig or containerized, VPC peering to the solo topology would be very helpful.


@kenny both points true, we have craptaculous CLI automation for that stuff


@U072WS7PE Those tools are expensive to develop, especially on a small team. We need to focus on product development, not tools to work with our database. If a database requires a craptaculous amount of CLI automation to use it in common use cases, it should provide that automation to its users.

👍 1

We’ve discovered that any call to a user function in a not-join will cause something to be recompiled every time we invoke the query. We know because criterium doesn’t converge. Is this expected?


(`not` works fine.)


Do you need to remove :proxy-port from the client arg-map in production?


@kenny: I think the proxy-port should only be there if you connect through the socks proxy. we don't have that parameter in our solo deployments either, only for local dev


I have :proxy-port set in my config and I'm getting Connection refused, not the SOCKS4 tunnel failed message.


Removing :proxy-port fixed it. I suggest adding that to the docs.


Deploying an ion is failing at the ValidateService step. The Log Trail in CodeDeploy has a bunch of [stdout]Received 503.


@kenny check your cloudwatch logs


Are there docs on what to look for? There's a lot of stuff in there.


There are a bunch of these under the Alerts search.


Turns out my datomic config was not correct causing the those misleading alerts. It'd be much more obvious if the regular anomaly was thrown saying it cannot connect.


You guys are the best lol


If my Ion returns a 500 and there are no Exceptions in the log, where else should I look?


If I run my Ion via the API Gateway, I receive this in the logs:

Fri Sep 07 23:08:30 UTC 2018 : Endpoint response body before transformations: {"headers":{"Content-Type":"application\/transit+json","Set-Cookie":["ring-session=a8d0bf20-fe5b-4a3a-9d4d-9299003ce1dd;Path=\/;HttpOnly"]},"statusCode":200,"body":"WyJeICJd","isBase64Encoded":true}
Fri Sep 07 23:08:30 UTC 2018 : Endpoint response headers: {Date=Fri, 07 Sep 2018 23:08:30 GMT, Content-Type=application/json, Content-Length=198, Connection=keep-alive, x-amzn-RequestId=ef88cd93-b2f2-11e8-8a46-7fe9b475b814, x-amzn-Remapped-Content-Length=0, X-Amz-Executed-Version=$LATEST, X-Amzn-Trace-Id=root=1-5b9304ee-cb4b86778c5717156acdceed;sampled=0}
Fri Sep 07 23:08:30 UTC 2018 : Execution failed due to configuration error: Malformed Lambda proxy response
Fri Sep 07 23:08:30 UTC 2018 : Method completed with status: 502


It may be the headers. I'm just using the regular Ring cookies middleware.


That must be it. The web docs say :headers is a map string->string which does not adhere to the Ring Spec for responses 😞


Looks like others have ran into this too: