AWS Lambda failure: "Could not load platform constants for OpenFlags" #5379
Comments
|
Per the issue creation notes, I just put some extra tracing code in my Lambda handler to run and capture the |
|
@SFEley I would try |
|
Thank you for the suggestion @mkristian! I just tried it, and unfortunately got the same error. From the stacktrace looks to me as if it's not having problems finding classes to load, but rather failing upon Ruby language initialization when it sets up the File class. Some constant to do with file modes or such isn't being set correctly, it looks like. I'm trying to investigate further now by understanding the code in jnr-constants but it's been slow going. |
|
the constant loading has some classloader fiddling but I was a bit uncertain if the IsolatedSCriptingContainer helps. |
|
@SFEley maybe this still works: https://github.com/mkristian/aws-lambda-jruby/blob/master/src/main/java/AWSLambdaJRuby.java |
|
I suspect that the detection logic to load constants is stumbling on something on Lambda. Would it be possible for you to get the full java -version string from there? Or at least dump the Java system properties (ENV_JAVA or java.lang.System.get_properties from Ruby) so we can see how this platform is being described. |
|
@headius Thank you so much! Ruby is crashing on initialization so I can't get anything from there, but I added some extra trace code to my Java wrapper to dump the system properties into the Lambda logs. Here they are: |
|
A bit more info: I've spent some time today setting up an AWS instance with the documented Lambda AMI and kernel version, so that I could try regenerating jnr-constants on it to see if anything was different. I'm about to make a (probably unmergeable) PR to show the diff, but the results are easily summarized:
From the recent log entries, @headius, I can imagine O_TMPFILE being missing in a current Linux environment will not brighten your day. But those are the only two things different from the constants in 0.9.11. I'm currently working on packaging the constants from my test into a custom JRuby build so that I can see if it resolves my original issue. |
|
There's the PR with the diff in question. I also found a reference to this same limitation in ruby/spec#368, although it's a different failure. (The JRuby initialization crash I'm seeing isn't because anything is trying to make tempfiles, but rather the OpenFlags constants simply seem to fail to load as a unit.) (Update: I also just noticed #5334 and couldn't help wondering if there was a relationship here too.) |
|
Ooops, so false alarm here. After updating @mkristian's sample project to JRuby 9.2.0.0 and testing it in Lambda, I found that it didn't error the same way. Going down the line to isolate differences between his project and mine, it turned out that the Gradle Shadow jar plugin was the culprit. I was letting it minimize dependencies and it was apparently doing it badly. Going back to the regular Gradle jar builder resolved the issue. I'm hitting another issue now with some gem dependency loading, but I know it's a completely different problem since Ruby is fully initialized by that point, and I have no doubt I'll figure it out. I'm closing this issue out with thanks to both of you (@mkristian and @headius) and apologies for taking up your time. |
|
@SFEley welcome anytime with these kind of problems |
Environment
Expected Behavior
This is an attempt to run Ruby business logic in the AWS Lambda serverless platform, using Lambda's java8 runtime environment. I have a thin Java class, LambdaHandler.java (gist), that simply sets up a JRuby
ScriptingContainerand loads a Ruby handler class in it, then forwards incoming Lambda events to it as they are received.The JRuby runtime is configured in the class as follows:
...and gets further setup when an instance of the class is initialized:
The expected behavior is that the rubyHandler object can be passed AWS Lambda JSON data as strings, and the return output will then be returned back to Lambda.
Actual Behavior
Tests are passing successfully on my local development machine (MacOS). When a shadow jar file with JRuby and all of this logic is uploaded to AWS, however, testing any Lambda event fails with the following brief stacktrace
At the recommendation of enebo in the JRuby IRC channel, I attempted it again with the latest jruby-complete-9.2.1.0-SNAPSHOT.jar from nightly builds. It failed with the same error and a nearly identical stacktrace
From just the class names in the trace, my initial guess is that the Amazon Linux platform isn't being recognized correctly in the JNR Constants, or else some restriction in the Lambda image's filesystem is causing file capability tests to fail. (Restrictions are set so that only the /tmp directory is writable.). I haven't had the opportunity to probe deeper and determine exactly what constant may be failing or why.
My hope is that someone here may be able to shed some light on how to fix it (perhaps by supplying additional information to Java before container setup?) or to work around the problem. Thank you very much in advance for your time and consideration.
The text was updated successfully, but these errors were encountered: