Initialize Servlets at construction - in the initialize() method

[sapessi]

• Framework version: 1.4
• Implementations: Spring
• Reported in: Spring Boot Lambda Startup multiple times #210

Scenario

SpringLambdaContainerHandler only creates a new instance of DispatcherServlet in the initialize() method and registers it with the context. The filter chain will then call the servlet's init() method lazily when the servlet is actually needed. This causes the initialize() method of SpringLambdaContainerHandler to return very quickly, making the asynchronous initialization wrapper less useful.

Expected behavior

Initialize the Servlet during the container handler initialization. The servlet specs seem to leave this up to the implementation:

After the servlet object is instantiated, the container must initialize the servlet before
it can handle requests from clients.

[kartoffelsup]

I've (hackily and temporarily) implemented my own Async Initializer and noticed that the jvm startup also needs to be taken into account when calculating the maximum time to wait on the init.

This is called in the static block of my LambdaHandler:
07:16:16 2019-10-15 07:16:16 INFO AsyncHandlerInitializer:26 - Starting async init of handler on thread: Thread-1
And I let it wait for init for about ~7 seconds:
07:16:23 2019-10-15 07:16:23 INFO AsyncHandlerInitializer:46 - Returning from AsyncHandlerInitializer#init. Waited for: '7197ms'
But it says the init duration was 9+ seconds:
07:16:30 REPORT RequestId: asdf Duration: 6141.40 ms Billed Duration: 6200 ms Memory Size: 1600 MB Max Memory Used: 276 MB Init Duration: 9265.40 ms

It seems that at least 2 seconds are used for the jvm (or something else I do not see) to startup?

[sapessi]

@kartoffelsup the JVM start is pretty quick - enabling X-Ray on the function will give you a good idea of how long the JVM startup takes in the initialization step. However, the JVM may also be busy loading other classes before it gets to the initializer, that's where the time may be going (just guessing).

To address this, in my samples I take a measurement of the start time first, before the JVM gets to the heavier init instructions. Check out this springboot2 test.

[kartoffelsup]

@sapessi thanks, I've enabled X-Ray and it indeed seems to take around 1-3 seconds (varies a lot) for the JVM to start (probably because my archive is about 50mb). So it would be desirable if the grace period in AsyncInitializationWrapper could be configurable (otherwise I would have to manipulate the actual start time that is passed as constructor parameter)

[sapessi]

Thanks for the feedback @kartoffelsup - We'll certainly make it configurable in the next release. Let me also dig into any other options to account for that time automatically. I'll update this issue as I find out more.

[kartoffelsup]

It seems one can use ManagementFactory.getRuntimeMXBean().getStartTime(); to get the actual JVM start time. I'm using this now for my temp solution.

[sapessi]

Thanks a great find. Thanks for the update @kartoffelsup!

[sapessi]

Hey @kartoffelsup I've made changes for both issues and committed them to the v1.5 branch. Would be great if you could test with 1.5-SNAPSHOT from the branch. You can take a look at the last two commits (they reference this issue)

[kartoffelsup]

Hi, thanks for the update. I'll try it out ASAP :)

[kartoffelsup]

@sapessi Works great now, after increasing the initialization timeout:

SpringLambdaContainerHandler.getContainerConfig().setInitializationTimeout((int) TimeUnit.SECONDS.toMillis(20L));

Not sure if 10 seconds is a good default, since we are expecting it to take longer when using the async initializer?

[sapessi]

Fair @kartoffelsup - I'll look at increasing it to a sane default. Need to balance cost and not getting in the way.