optaplanner with aws lambda

651 views Asked by At

I am using optaplanner to solve a scheduling problem. I want to invoke the scheduling code from AWS Lambda (i know that Lambda's max execution time is 5 minutes and thats okay for this application)

To achieve this I have build a maven project with two modules: module-1: scheduling optimization code module-2: aws lambda handler ( calls scheduling code from module-1)

When i run my tests in IntelliJ Idea for module-1(that has optaplanner code), it runs fine.

When I invoke the lambda function, i get following exception:

java.lang.ExceptionInInitializerError:    
java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
 at org.kie.api.internal.utils.ServiceRegistry.getInstance(ServiceRegistry.java:27)
 ...
Caused by: java.lang.RuntimeException: Child services [org.kie.api.internal.assembler.KieAssemblers] have no parent
 at org.kie.api.internal.utils.ServiceDiscoveryImpl.buildMap(ServiceDiscoveryImpl.java:191)
 at org.kie.api.internal.utils.ServiceDiscoveryImpl.getServices(ServiceDiscoveryImpl.java:97)
 ...

I have included following dependency in maven file: org.optaplanner optaplanner-core 7.7.0.Final

Also checked that jar file have drools-core, kie-api, kei-internal, drools-compiler. Does anyone know what might be the issue?

2

There are 2 answers

3
Geoffrey De Smet On

Sounds like a bug in drools when running in a restricted environment such as AWS-lambda. Please create a JIRA and link it here.

2
Luis Woods On

I was getting the same error attempting to run a fat jar containing an example OptaPlanner project. A little debugging revealed that the problem was services was empty when ServiceDiscoveryImpl::buildMap was invoked; I was using the first META-INF/kie.conf in the build, and as a result services were missing from that file. Naturally your tests would work properly because the class path would contain all of the dependencies (that is, several distinct META-INF/kie.conf files), and not the assembly you were attempting to execute on the lambda.

Concatenating those files instead (using an appropriate merge strategy in assembly) fixes the problem and appears appropriate given how those are loaded by ServiceDiscoveryImpl. The updated JAR runs properly as an AWS lambda.

Note: I was using the default scoreDrl from the v7.12.0.Final Cloud Balancing example.