Add ID resolver for AWS lambda #10
Conversation
|
|
||
| public function __destruct() | ||
| { | ||
| $this->release(); |
There was a problem hiding this comment.
Could we do an App::terminating callback in the constructor rather than a destruct?
Or we might end up releasing before verbs commits?
There was a problem hiding this comment.
What's the advantage of App::terminating over __destruct? I think destruct is a little more flexible, but I could be wrong…
There was a problem hiding this comment.
If destruct happens after laravel tears down, could the cache be disconnected?
There was a problem hiding this comment.
Just to add some extra fun... If you're running octane on lambda, then you're likely to run into problems relying on __destruct(), but you're also likely to run into problems with the singletons below.
There was a problem hiding this comment.
The solution for Octane is to use a scoped singleton. Here's the relevant section of the docs:
Binding Scoped Singletons
The scoped method binds a class or interface into the container that should only be resolved one time within a given Laravel request / job lifecycle. While this method is similar to the singleton method, instances registered using the scoped method will be flushed whenever the Laravel application starts a new "lifecycle", such as when a Laravel Octane worker processes a new request or when a Laravel queue worker processes a new job
Snowflakes/etc rely on unique datacenter and worker IDs to operate. Because AWS lambdas are different machines each time, it's impossible to assign each a unique worker/device ID.
This PR adds a new ID resolution mechanism that uses cache locks to acquire a unique ID when required, and then release that ID when the process is terminated. This means that you can effectively have 1024 processes generating unique snowflake IDs in parallel.
By default, Bits will use this mechanism if the
AWS_LAMBDA_FUNCTION_NAMEenvironmental variable is set.