-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java snapstart issue #808
Comments
Interesting! I will test with a sleep to see if that affects the number. Thanks for reporting it @ledoux7 |
I could not reproduce, when you say |
I don't have any offical source unfortunately, but from my personal experience with using snapstart (with Kotlin) it only seems to work consistently if we do a fresh deploy from cdk. So changing something like an env variable through the console doesn't trigger the rebuild of the snapshot or something. I haven't dug that deep into it, but thought it only was an issue of time. Could you maybe add a log line to the init part of the handler to confirm if it is run or not? It should not be run if snapstart is used. |
Or the problem might be it does not invoke the correct version, And I'm not really understanding if this is doing what it should, would not the new versions of the lambda not be deployed by the time you call async fn invoke_snapstart<'a>(
runtime: &Runtime,
retry: &RetryManager,
lambda_manager: &LambdaManager<'a>,
) -> Result<(), Error> {
let arns = lambda_manager.list_versions_by_function(runtime).await?;
for i in 0..10 {
info!("snapstart run #: {}", i);
if let Some(arn) = arns.get(i) {
info!("arn = {}", arn);
retry
.retry_async(|| async {
lambda_manager
.update_function_configuration(&runtime.function_name())
.await
})
.await?;
info!("function updated to ensure cold start");
thread::sleep(Duration::from_secs(5));
retry
.retry_async(|| async { lambda_manager.invoke_function(arn).await })
.await?;
info!("function invoked");
}
}
Ok(())
} A better approach could be to create an alias named |
im gonna second that. put 2 different versions of the same code on the lambda (e.g. version 1 and 2 that you can swap between), set the container concurrency to 1 lambda at a time and use an alias. then, to be completely sure you have started a new container, you can change the version the alias is using and invoke against that alias afterwards. you'll still want to sleep 5 to ensure your next invoke isn't waiting for the previous container to be killed. |
I don't think the current updating function configuration trick makes it so your tests are actually using snapstart based on the numbers. It possibly takes some time before AWS has made the snapstart feature enabled on newly updated functions
The text was updated successfully, but these errors were encountered: