Clojurians Log v2

Is it safe to assume cognitect.aws.client.api/client is non-blocking?

^^ @ghadi @dchelimsky

It reads from the file system.

@kenny does that answer your question?

I think so. Probably safest to create clients not in a go block then, right?

I've seen https://github.com/cognitect-labs/aws-api/issues/41 on no current support for timeouts in aws-api. Is there a workaround? This seems like a big hole. Am I supposed to let requests hang around forever if AWS would let them?

we're planning on supporting this explicitly, but for now you can use the async API and put an external timeout on your call

(async/alts! [aws-response your-timeout])

Couldn't this result in lots of resources left hanging though?

meaning open http connections?

Yes

right

quantifying it will depend on your use-case

my guess is that we can/will use the http client library's timeout mechanism

what APIs are you using, or is this an abstract question?

SQS ReceiveMessage offers a explicit long-polling timeout

for example

Both, I suppose. I slept my computer and went for lunch. When I came back, I ran an API call to AWS lambda with a <!! around the aws-api response. It sat for several minutes with no response. I don't know exactly what caused this, but it made the issue very obvious and quite frightening. If that could happen, it could (we must assume it will) lock up the calling thread for who knows how long. I can, and should, add the alts! but if something like this were to happen often in production, it could easily eat up lots of resources.

(we will be calling this particular api very often)

InvokeLambda?

:op :Invoke

Like so

(aws-api-async/invoke
  (async/<! @*lambda-client)
  {:op      :Invoke
   :request {:FunctionName   function-name
             :InvocationType "RequestResponse"
             :Payload        (transit/encode-transit query-request)}})

Well, that's newer. The weird (async/<! @*lambda-client) wasn't there before.

if you care about the lambda response, you have to wait for it though

I care about it but not enough to wait minutes 🙂

in that case put a timeout on the Lambda itself

It should never take that long. After the lambda is hot, it executes in 10s of millis.

default timeout is 3 seconds on a lambda

max is 15 minutes

This is a Datomic Ion. Guessing there's some default timeout on it.

I see 1 min in the AWS console. I waited at least 5 mins.

that would be an interesting repro for the datomic team

the lambda proxies that Ions spin up have a default 60s timeout

So for whatever reason, it sat for 5 mins before I restarted the REPL.

I bet this isn't an http timeout issue at all, my guess is a deadlock core async threadpool

Certainly possible. From the REPL history, I had only ran the code 3 times: twice before lunch and the 1 after. That wouldn't deadlock the threadpool, right?

This code is also incredibly simple. No obvious blocking calls.

It depends on what other code is running. You can look at thread dumps or manually schedule a job on the core async threadpool to see if it runs

The async API will also retry operations with some kind of backoff for certain errors

That could have brought the total time to return above 5 mins if the Lambda kept timing out.

It doesn't tell you if that is happening, but you can configure that stuff when creating a client, so you could pass it a function that logs something