AWS Lambda (Java)#2901
Conversation
eamsden
force-pushed
the
ea/aws-lambda
branch
3 times, most recently
from
804fbaf to
b7a2000
Compare
Add LambdaWorker overloads that accept an invocation configurator so handlers can adjust worker options using the AWS Lambda Context before Temporal service stubs, clients, and workers are created. Copy the base options for each invocation, allow required fields such as task queue to be supplied dynamically, and keep invocation-local shutdown hooks from leaking across warm invocations. Run those hooks if the per-invocation configurator or final option validation fails. Document the new overload and cover the lifecycle behavior with unit tests.
| private static Sleeper sleep() { | ||
| return duration -> Thread.sleep(duration.toMillis()); | ||
| } | ||
|
|
||
| interface Sleeper { | ||
| void sleep(Duration duration) throws InterruptedException; | ||
| } | ||
|
|
||
| interface NanoClock { | ||
| long nanoTime(); | ||
| } | ||
|
|
||
| private static NanoClock systemNanoClock() { | ||
| return System::nanoTime; | ||
| } |
There was a problem hiding this comment.
Do we need all our own stuff here for this? I know there's https://docs.oracle.com/javase/8/docs/api/java/time/Clock.html
There was a problem hiding this comment.
Saw this got renamed but still curious if there's anything off the shelf we could've used here (fine if not)
There was a problem hiding this comment.
I must have messed up the rebase somehow. This was supposed to have been dealt with. Let me check.
There was a problem hiding this comment.
Nevermind I forgot a note I wrote to myself, for NanoClock/MonotonicClock there's no narrower standard library interface than LongSupplier which is...any 0-argument function that returns long. So I think Sleeper can go in favor of Consumer<Duration> (very few things you can do with a void-valued function that takes a duration other than sleep, unless it's a setter or something), but MonotonicClock should stay. These interfaces exist to inject not-actually-sleeping methods for the Lambda-specific timers, solving a similar problem to workflow time-skipping.
Sushisource
left a comment
Sushisource
left a comment
There was a problem hiding this comment.
Ah - another thing that comes to mind here, I implemented the OTel support as a plugin in the other langs, we should probably do the same here (looks like Justin mentioned this in the .NET one too)
Sushisource
left a comment
Sushisource
left a comment
There was a problem hiding this comment.
Overall I think this makes sense, maybe with one possible renaming suggestion here.
Plz get a Java owner approval before merging.
|
|
||
| public final class Handler implements RequestHandler<Object, Void> { | ||
| private static final RequestHandler<Object, Void> WORKER = | ||
| LambdaWorker.run( |
There was a problem hiding this comment.
I'm actually wondering if we should call this define instead of run.
In the other langs the run still looks like actually running, even if it is ultimately doing the same thing semantically. Here it's more obvious that the worker isn't really running, per se, but is rather set up to be run by the handler.
2 participants
What was changed
Add contrib support for running Java workers on AWS Lambda
Why?
Towards SDK parity for AWS Lambda support for serverless workers
Checklist
Closes (NA)
How was this tested:
Full E2E deploy and workflow run of a Lambda worker, with and without OTel tracing and metrics
Any docs updates needed?