Lambda Component timeout on Greengrass V2

0

I'm testing a lambda function that I'm using as a component in a Greengrass V2 environment. I'd like it to have a timeout of 5 minutes so I thought I'd just have to set the component configuration "timeoutInSeconds" to 300. But this doesn't seem to be working. The lambda function is timing out after about 6 seconds and I don't know why.

The logs show the following when I run the lambda component.

2023-11-17T19:19:10.464Z [INFO] (ggv2-lwc-main-collector-component#1-lifecycle) com.aws.greengrass.lambdamanager.UserLambdaService: service-set-state. {serviceInstance=1, serviceName=ggv2-lwc-main-collector-component, currentState=FINISHED, newState=INSTALLED}
2023-11-17T19:19:10.469Z [INFO] (ggv2-lwc-main-collector-component#1-lifecycle) com.aws.greengrass.lambdamanager.UserLambdaService: service-set-state. {serviceInstance=1, serviceName=ggv2-lwc-main-collector-component, currentState=INSTALLED, newState=STARTING}
2023-11-17T19:19:11.420Z [INFO] (Copier) com.aws.greengrass.lambdamanager.UserLambdaService: Startup script exited. {exitCode=0, serviceInstance=1, serviceName=ggv2-lwc-main-collector-component, currentState=STARTING}
2023-11-17T19:19:11.420Z [INFO] (ggv2-lwc-main-collector-component#1-lifecycle) com.aws.greengrass.lambdamanager.UserLambdaService: service-set-state. {serviceInstance=1, serviceName=ggv2-lwc-main-collector-component, currentState=STARTING, newState=RUNNING}
2023-11-17T19:19:11.699Z [INFO] (Thread-6) software.amazon.awssdk.eventstreamrpc.RpcServer: New connection code [AWS_ERROR_SUCCESS] for [Id 199, Class ServerConnection, Refs 1](2023-11-17T19:19:11.699280Z) - <null>. {}
2023-11-17T19:19:11.704Z [INFO] (Thread-6) software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler: aws.greengrass#GreengrassCoreIPC authenticated identity: ggv2-lwc-main-collector-component. {}
2023-11-17T19:19:11.704Z [INFO] (Thread-6) software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler: Connection accepted for ggv2-lwc-main-collector-component. {}
2023-11-17T19:19:11.704Z [INFO] (Thread-6) software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler: Sending connect response for ggv2-lwc-main-collector-component. {}
2023-11-17T19:19:11.714Z [INFO] (Thread-6) com.aws.greengrass.secretmanager.SecretManagerService: secret-access. requested secret. {secret=jsas-control-dev-lwc-preshared-secret, serviceName=aws.greengrass.SecretManager, currentState=RUNNING, Principal=ggv2-lwc-main-collector-component}
2023-11-17T19:19:16.682Z [ERROR] (pool-1-thread-4) com.aws.greengrass.lambdamanager.WorkManager: work-item-timeout. lambda work item timed out. {instanceId=1, workItem=67f7b1a2-0a00-49d9-85bb-6e96e5257700, arn=arn:aws:lambda:us-west-2:531381891715:function:ggv2-lwc-main-collector-component:26}

When the timeout happens the lambda is just waiting for something that won't happen because the environment won't allow it (it's a test environment that isn't ready yet). But it never has any errors and just gives this message when it times out.

2023-11-17T19:19:16.769Z [INFO] (pool-2-thread-318) ggv2-lwc-main-collector-component: Caught SIGTERM. Stopping runtime.. {serviceInstance=1, serviceName=ggv2-lwc-main-collector-component, currentState=STOPPING}

What am I missing here? I've also tried setting a timeout of 300s in the following places:

  • In the lambda function itself
  • In the component that contains the lambda function I've tried these settings
    • statusTimeoutInSeconds
    • timeoutInSeconds
  • In the deployment config for the aws.greengrass.LambdaManager
    • getResultTimeoutInSecond

None of these seem to affect the behavior.

slynch
asked a year ago440 views
2 Answers
2

This timeout is controlled by the lambda's timeoutInSeconds option which is part of the lambda component configuration. Change it by making a deployment which uses the MERGE operation to update the timeout field with the value you want.

If you make a new version of the lambda component with an updated timeout value then to apply this to your device you must deploy the new version of the lambda component using "RESET": [""] so that the component will use the new default values in the new component version. https://docs.aws.amazon.com/greengrass/v2/developerguide/update-component-configurations.html#reset-configuration-update

With all this being said, I do not recommend using lambdas for new development. The preferred way to develop for Greengrass V2 is using native components such as shown in this tutorial: https://docs.aws.amazon.com/greengrass/v2/developerguide/defer-component-updates-tutorial.html.

Cheers,

Michael

AWS
EXPERT
answered a year ago
profile pictureAWS
EXPERT
Greg_B
reviewed a year ago
0

Ok thank you! That worked. I was putting the timeout into the creation of the component itself - which is created through CloudFormation. I didn't realize that I actually need to put it into the deployment as a merge config.

As for using lambdas vs native components, this is part of our upgrade from Greengrass v1 to v2 and the quickest way for us to move forward seemed to be to just reuse our lambdas that we already have from the v1 setup.

Having said that, we do plan on migrating to native components eventually and briefly looked into that paradigm. One thing that I couldn't figure out though, was how to control a native component to be "on-demand" like a lambda function. Everything I saw seemed to point to native components existing for the lifetime of the deployment without the ability to be instantiated as a result of an event and torn down after processing that event. Can you point me in the right direction to get this type of behavior from a native component?

Thank you!

slynch
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions