aws

http://status.aws.amazon.com/ https://www.expeditedssl.com/aws-in-plain-english
2020-03-26T00:38:40.008100Z

@kenny seems like a reasonable near term approach.

kenny 2020-03-26T00:50:53.009Z

When you have free time, curious about your thoughts on the real solution.

kenny 2020-03-26T00:52:39.009500Z

Implicit creds fetch to a separate pool?

kenny 2020-03-26T00:57:09.011200Z

Separate pool for creds fetch is a half solution too. I suppose you could have arbitrarily nested cred fetching that needs to run.

kenny 2020-03-26T01:04:11.012200Z

Returning a channel would probably fix this entirely, but Iโ€™m assuming thereโ€™s a reason itโ€™s run in a thread.

2020-03-26T01:22:40.012400Z

It does return a channel - we're just putting on that channel in a thread from that pool. Making that async/thread is my first instinct. So it's obviously wrong ๐Ÿ˜‰ If you have an opinion about that, I'm all ears. Also want to hear from @ghadi.

kenny 2020-03-26T15:58:04.012800Z

I deployed workaround with async-fetch-pool set to 10 yesterday evening. The service has been healthy since. For those looking for a workaround, I can say with high certainty that this will fix it. Wrapping in async/thread as @dchelimsky says sounds like another potential solution. I do believe that results in an unbounded number of potential threads to be created. In this case, that should always be small I think.

2020-03-26T16:22:48.013Z

It's bound by core.async's threadpool size, which defaults to 8, but you can configure it via the clojure.core.async.pool-size system property: https://github.com/clojure/core.async/blob/1c5efa72ebf65cd23315311d2bc3d890b780696e/src/main/clojure/clojure/core/async/impl/exec/threadpool.clj

kenny 2020-03-26T16:51:21.013400Z

I don't think async/thread is bound by that. That's for the go blocks.

kenny 2020-03-26T16:52:12.013600Z

thread calls thread-call which uses thread-macro-executor, defined as a CachedThreadPool https://github.com/clojure/core.async/blob/1c5efa72ebf65cd23315311d2bc3d890b780696e/src/main/clojure/clojure/core/async.clj#L471.

kenny 2020-03-26T16:53:00.013900Z

The maximumPoolSize for core.async's call to newCachedThreadPool is Integer.MAX_VALUE.

1๐Ÿ‘
2020-03-26T17:14:50.014400Z

So it is bounded ๐Ÿ˜‰. But yeah, we'll need to constrain that a bit more.

kenny 2020-03-26T18:10:16.016100Z

I think CredentialsProvider fetch needs to return a channel. That would move the problem to the user.

kenny 2020-03-26T18:11:05.017200Z

Also, I think that is effectively the same as unbounded. Fairly certain bad things will happen as you approach the max int value.

2020-03-26T21:02:45.017400Z

Oh yeah, I was making a joke about it being bounded.

kenny 2020-03-26T21:03:22.017600Z

Ohh, got it ๐Ÿ™‚

2020-03-26T21:03:28.017800Z

re: returning a channel from fetch, that would be a breaking change so we won't do that, but we could add fetch-async to the CredentialsProvider and return a channel from that (and use that in our implementations).

kenny 2020-03-26T21:04:43.018Z

It would indeed. Deprecating the current method seems like a good idea since it can result in a deadlock. Deadlocks are one of the worst problems to hit.

2020-03-26T21:04:54.018200Z

I'll have some time to look at this and talk some things over with other contributors tomorrow so we should have at least a direction. I'll follow up on the issue at that point.

1