Deploying Trellis LDP as an AWS Lambda function

[Andrew McConnell]

I'm attempting to run Trellis as a Lambda function in AWS. I've looked at the lambda code in the old trellis-ext-aws repository, so I think that at least some effort has been made.

After successfully deploying Trellis in the Java11 Lambda runtime, I get 500 errors invoking it through API Gateway. The underlying stack trace is this:

START RequestId: c778f593-d7a2-47a5-9b63-1bc9f3be16db Version: $LATEST
12:25:33.914 [main] INFO  c.a.s.p.jersey.JerseyHandlerFilter - Initialize Jersey application handler
12:25:33.914 [main] DEBUG c.a.s.p.i.servlet.FilterChainHolder - Starting REQUEST: filter 0-JerseyFilter
12:25:34.054 [main] DEBUG c.a.s.p.j.JerseyServletResponseWriter - Suspend
12:25:34.055 [main] ERROR c.a.s.p.j.JerseyServletResponseWriter - failure
javax.ws.rs.ProcessingException: Attempt to suspend a connection of an asynchronous request failed in the underlying container.
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:375)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
at com.amazonaws.serverless.proxy.jersey.JerseyHandlerFilter.doFilter(JerseyHandlerFilter.java:91)
at com.amazonaws.serverless.proxy.internal.servlet.FilterChainHolder.doFilter(FilterChainHolder.java:90)
at com.amazonaws.serverless.proxy.internal.servlet.AwsLambdaServletContainerHandler.doFilter(AwsLambdaServletContainerHandler.java:150)
at com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:185)
at com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:77)
at com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxy(LambdaContainerHandler.java:211)
at com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxyStream(LambdaContainerHandler.java:246)
at com.iceeleven.TrellisLambdaHandler.handleRequest(TrellisLambdaHandler.java:31)
at lambdainternal.EventHandlerLoader$2.call(EventHandlerLoader.java:897)
at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:228)
at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:162)
at lambdainternal.AWSLambda.main(AWSLambda.java:157)
12:25:34.093 [main] ERROR c.a.s.p.i.LambdaContainerHandler - Error while handling request
javax.ws.rs.InternalServerErrorException: Jersey failed to process request
at com.amazonaws.serverless.proxy.jersey.JerseyServletResponseWriter.failure(JerseyServletResponseWriter.java:126)
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:436)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:261)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
at com.amazonaws.serverless.proxy.jersey.JerseyHandlerFilter.doFilter(JerseyHandlerFilter.java:91)
at com.amazonaws.serverless.proxy.internal.servlet.FilterChainHolder.doFilter(FilterChainHolder.java:90)
at com.amazonaws.serverless.proxy.internal.servlet.AwsLambdaServletContainerHandler.doFilter(AwsLambdaServletContainerHandler.java:150)
at com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:185)
at com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:77)
at com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxy(LambdaContainerHandler.java:211)
at com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxyStream(LambdaContainerHandler.java:246)
at com.iceeleven.TrellisLambdaHandler.handleRequest(TrellisLambdaHandler.java:31)
at lambdainternal.EventHandlerLoader$2.call(EventHandlerLoader.java:897)
at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:228)
at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:162)
at lambdainternal.AWSLambda.main(AWSLambda.java:157)
Caused by: javax.ws.rs.ProcessingException: Attempt to suspend a connection of an asynchronous request failed in the underlying container.
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:375)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
... 20 common frames omitted

I was able to reproduce the issue with a trivial Jersey resource that uses @Suspended AsyncResponses (which is what TrellisHttpResource uses):

@GET
public void doSomethingAsync(@Suspended final AsyncResponse response) {
    response.resume("ASYNC SUCCESS?");
}

So, I don't think its a Trellis issue per se. I'd place a small wager that the Lambda runtime is disallowing this since AWS is billing by execution time.

I'm wondering if anyone has been able to deploy in Lambda successfully?

Thanks.

[Aaron Coburn]

Hi Andrew,

That's very interesting. As you noticed, when I ported the AWS features into the trellis-extensions repository, I did not include any support for deploying to lambda. That was primarily because that support was very experimental and it wasn't clear to me that it even worked properly in the first place. 

Having a lambda-based deployment option seems really useful, but I would probably begin from a slightly different angle than what you see in the old trellis-ext-aws code. Because much of the current effort has been around supporting JavaEE microprofile, especially Quarkus, I would take a look here to start: https://quarkus.io/guides/amazon-lambda. This would basically involve implementing Amazon's RequestHandler interface, similar to how it is done in the old code. At that point, adding a dependency on quarkus-amazon-lambda *should* work, though it's worth noting that the quarkus support for this is still in preview.

If you make progress on that, I would be very interested in hearing how that goes.

Cheers,

Aaron

--
You received this message because you are subscribed to the Google Groups "Trellis LDP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trellis-ldp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trellis-ldp/d7d2b273-39f0-4e04-9d2f-5b76b81f007d%40googlegroups.com.

[Andrew McConnell]

That was very helpful. I'm think close to getting it running using the quarkus amazon-lambda-http extension.

[Andrew McConnell]

I got it running this evening in non-native mode under AWS Lambda and Quarkus amazon-lambda-http. I've still got an issue with API Gateway not decoding the Base64 response from the lambda, but I think that I'm out of the woods!

Thanks for the help.