Clojurians Log v2
aws 2022-11-24
@grzm I'm looking at switching from the Cognitect AWS API to awyeah so we can get around the Jetty 9 issue. Your docs say:
> The awyeah-api client does not auto-refresh AWS credentials. The aws-api behavior relies on features that aren't present in babashka, and I haven't figured out an alternative implementation of the behavior. My use case is short-lived scripts, where JVM start-up time can dwarf script execution time: credentials don't have much time to get stale.
Does that mean if I create a basic-credentials-provider and a client based on it at startup in a long-lived process and use it for uploading stuff to S3, after some period of time, it will fail because the credentials have gone stale?
Since we don't upload to S3 very often, it would be easy for us to recreate the whole client each time we need to do a short batch of uploads -- if we have to.
If it doesn't handle the STS refresh then it's eventually going to fail.
if your architecture can use presigned urls, then move further that direction
Yeah, we use presigned URLs.
Feel free to bug me about missing classes
Yup to all of this. The short answer is there's stuff for credentials refresh in aws-api that isn't directly avaiable in Babashka (stuff around java.util.concurrent.ScheduledExecutorService, IIRC), and there are easy-enough workarounds to handling refreshing credentials as needed.
Most of these missing classes are in bb now - the only one missing is ThreadLocal and ThreadFactory I think
Cheers. I'll take a look. IIRC, ThreadLocal is only used to make SimpleDateFormat thread-safe (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228335), and awyeah-api uses the JDK9 java.time stuff. aws-api currently maintains support for JDK8.