Using micronaut on CloudRun fully managed - java

I tried to run micronaut framework on Cloud Run for testing clod start performance.
When I deploy in command line, I have this issue:
Deploying...
Creating Revision... Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable. Logs for this revision might contain more information....failed
Deployment failed
ERROR: (gcloud.beta.run.deploy) Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable. Logs for this revision might contain more information.
However, I tested several dockerfile configuration, and I think that my last one is good for passing the EnvVar port to the expected Micronaut EnvVar:
FROM gradle:jdk11-slim as builder
COPY --chown=gradle:gradle . /home/gradle/src
WORKDIR /home/gradle/src
RUN gradle build
FROM adoptopenjdk/openjdk11-openj9:jdk-11.0.1.13-alpine-slim
COPY --from=builder /home/gradle/src/build/libs/micronaut-jib-cr*.jar micronaut-jib-cr.jar
ENV MICRONAUT_SERVER_PORT=${PORT}
EXPOSE ${PORT}
CMD java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dcom.sun.management.jmxremote -noverify ${JAVA_OPTS} -jar micronaut-jib-cr.jar
So, I went deeped in the Cloud Run logs, and I saw an another cause of this problem
D Container Sandbox Limitation: Unsupported syscall setsockopt(0x8,0x1,0xc,0x2ae1273fc05c,0x4,0x32)
D Container Sandbox Limitation: Unsupported syscall setsockopt(0x8,0x6,0x6,0x2ae1273fc03c,0x4,0x3a)
A Error: Could not find or load main class micronaut.jib.cr.Application
A Caused by: java.lang.ClassNotFoundException: micronaut.jib.cr.Application
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753ef50,0x2,0x2ae12753ef50)
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753ef50,0x2,0x2ae12753ef50)
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753f440,0x2,0x2ae12753f440)
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753f440,0x2,0x2ae12753f440)
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753f440,0x2,0x2ae12753f440)
D Container Sandbox Limitation: Unsupported syscall semctl(0x1,0x0,0x2,0x2ae12753f440,0x2,0x2ae12753f440)
Is it a real wrong port usage ? In this case, can you help me with my dockerfile ?
If not, is it a known Cloud Run limitation ?
There is a work-around on micronaut to solve this syscall limitation ?
Thanks for your help

It's not a port issue. It looks like you hit a limitation of gvisor, which is the sandbox used by Cloud Run. Your container is trying to make a syscall that the sandbox does not (yet) support, which is causing the container to crash during start-up.

Indeed, John Hanley was right. My gradle build didn't reference the correct main class... I shame of this evident error. But I used Visual Studio Code for the first time (because it seems trendy!), and the package refactor is not as efficient as IntelliJ one ! (Or I haven't the right plugin!)
Thanks for your help, now it work perfectly (and more again with GraalVM packaging!)

Related

How do I resolve "Graphics Device initialization failed for : es2, sw" when running on WSL?

I am trying to setup okta-aws-cli-assume-role, but I have a Windows machine (please don't shoot me!). I think my problem is there is some graphical components, and when I run with a Ubuntu WSL, it can't find the appropriate device.
The full error is:
Graphics Device initialization failed for : es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
What should I do?
While some may suggest you a workaround for this problem, I suggest you to take a look at aws-sts docker solution: it uses headless browser under the hood, so there won't be any problems related to the graphics and it is more or less platform independent.
I was exactly in the same situation using WSL, so what I did:
created config.json as described in the Readme
ReadMe suggests to create a Dockerfile, but actually I never had to use it just passing the config parameters to the basic docker image like in the template file
As the result, aws token is generated inside the docker container and put into mounted $HOME/.aws folder, so you can easily call awscli from WLS.
Here is how to make docker working properly with WLS (in short, client in WLS, server installed on Windows with exposed daemon).
One more hint: use --profile=default when generating token, so you don't have to specify it every time you use awscli.

jna Native.LoadLibrary does not manage to load library on server (working in local)

I use JNA to load a c++ library (.so) in a java project. I package my library inside the jar, and load it from the jar when instantiating the java class that uses it. I do all this like so:
mvn install compiles the c++ code and packages the outcome dynamic library inside the jar.
I call in a static context when instantiating the LibraryWrapperClass the following
System.load( temp.getAbsolutePath() );
where temp is a temporary file containing the library which was found in the jar. This code is based on the work found here adamheinrich
- I call Native.loadLibrary(LIBRARYPATH) to wrap the library into a java class.
private interface Wrapper extends Library {
Wrapper INSTANCE = Native.loadLibrary( C_LIBRARY_PATH, Wrapper.class );
Pointer Constructor();
...
}
I run tests and validate that the library was found and up and running.
I use a java web project that depends on this project. It uses tomcat and runs fine in local.
My issue is that when I deploy on the server, the LibraryWrapperClass cannot instantiate. Error on server is:
java.lang.NoClassDefFoundError: Could not initialize class pacakgeName.LibraryWrapperClass
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.hibernate.annotations.common.util.StandardClassLoaderDelegateImpl.classForName(StandardClassLoaderDelegateImpl.java:57)
at org.hibernate.boot.internal.MetadataBuilderImpl$MetadataBuildingOptionsImpl$4.classForName(MetadataBuilderImpl.java:758)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.classForName(JavaReflectionManager.java:144)
at...
This error seems that the library is found, since there is not the UnsatisfiedLinkError exception thrown. But something else is failing. Do someone know what could happen? How could I debug?
I recall that everything works perfectly in local.
How could I debug?
1. with strace
strace will give you what files Tomcat is trying to open : strace -f -e trace=file -o log.txt bin/startup.sh
After this, look for packageName in log.txt, or other files not found with :
egrep ' open.*No such file' log.txt
2. with JConsole
Enable JMX, launch a JConsole, go to VM summary tab, and check/compare very carefully VM arguments/classpath/library path/boot class path
3. dependency listing with ldd
If a dependency issue is likely to be the problem, the ldd sharedLibraryFile.so command lists all the dependencies and allows to track which one might be missing.

Java/Spring application cannot start up on cloudfoundry: OutOfMemoryError Compressed class space

After deploying a new version of our Java/Spring Boot software to the Swisscom Developer Cloud, running on CloudFoundry, the startup suddenly failed with the following error: OutOfMemoryError: Compressed class space. So, we decided to deploy a previous version of the software, the version which was running actually just before: The same error occurred. We did not switch from Java7 to Java8, nor did we change any configuration. This leads to the question: Is this really an error on our side or rather on the server's side?
We then tried to increase the MaxMetaspaceSize by setting the variable JBP_CONFIG_OPEN_JDK_JRE to one of the following lines:
[jre: {version: 1.8.0_+}, memory_calculator: {memory_sizes: {metaspace: 128m}}]
{memory_calculator: {memory_sizes: {metaspace: 128m}}}
{memory_sizes: {metaspace: 128m}}
The application always warned, that the value of memory_sizes was invalid. What is the correct format of this YAML variable?
[ConfigurationUtils] WARN User config value for 'memory_sizes' is not valid, existing property not present
We then deleted the Java app and the database service on the Swisscom Developer Console and recreated it. It had no effect, the same error occured.
And finally, do you know why this error does suddenly occur, even with a version which was just running fine a few minutes ago?
EDIT:
This is the manifest ([database-service-name] and [application-name] were replaced):
---
path: .
instances: 1
buildpack: https://github.com/cloudfoundry/java-buildpack
services:
- [database-service-name]
applications:
- name: [application-name]
domain: scapp.io
host: [application-name]
memory: 1024M
disk_quota: 1024M
env:
SPRING_PROFILES_ACTIVE: stage, cloudfoundry
The Java buildpack version is (according to the logs):
2017-03-03 11:47:02 [STG/0] OUT -----> Java Buildpack Version: b08a692 | https://github.com/cloudfoundry/java-buildpack#b08a692
This command seems to be executed (in the logs after the crash):
2017-03-03 11:46:25 [APP/PROC/WEB/0] OUT vcap 8 0 99 10:46 ? 00:01:09 /home/vcap/app/.java-buildpack/open_jdk_jre/bin/java -Djava.io.tmpdir=/home/vcap/tmp -XX:OnOutOfMemoryError=/home/vcap/app/.java-buildpack/open_jdk_jre/bin/killjava.sh -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=68540K -XX:ReservedCodeCacheSize=240M -XX:CompressedClassSpaceSize=8731K -Xmx408104K -Djavax.net.ssl.trustStore=/home/vcap/app/.java-buildpack/container_certificate_trust_store/truststore.jks -Djavax.net.ssl.trustStorePassword=java-buildpack-trust-store-password -cp /home/vcap/app/. org.springframework.boot.loader.WarLauncher
The OutOfMemory error occurred because the Java buildpack was changed to use version 3.x of the memory calculator. Similar problems arising from this change are under discussion in GitHub issue 390. Please refer to this issue for details.
In general, v3.x of the memory calculator chooses values for various JVM memory settings based on the number of class files in the application and some default values which depend on the version of Java. It then sets the maximum heap size to the remaining amount of memory.
The previous version of the memory calculator was configured by setting JBP_CONFIG_OPEN_JDK_JRE. However, v3.x can be configured simply by setting the corresponding Java memory settings in JAVA_OPTS. For example, you could set the maximum metaspace size to 100 Mb as follows:
cf set-env app-name JAVA_OPTS '-XX:MaxMetaspaceSize=100m'
If you simply want a workaround, you can use the version of the Java buildpack released before the memory calculator change:
cf push -b https://github.com/cloudfoundry/java-buildpack.git\#v3.14 ...
comment from Swisscom Java developer:
For sure they will be reverting the memory heuristics to what they
were in 3.13 or at least refine the calculations. The current
recommendation to all customers is either
to use 3.13 or
to use some explicit options with the environment variable JAVA_OPTS.

Error when push Liberty for Java application in IBM Bluemix

when I run sample IBM Bluemix Liberty for Java application https://github.com/ibmjstart/bluemix-java-postgresql-uploader.git following error:
-----> Downloaded app package (1.9M)
-----> Downloaded app buildpack cache (4.0K)
OK
/var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:101:in build_pack': Unable to detect a supported application type (RuntimeError) from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:74:inblock in compile_with_timeout'
from /usr/lib/ruby/1.9.1/timeout.rb:68:in timeout' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:73:incompile_with_timeout'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:54:in block in stage_application' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:inchdir'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:in stage_application' from /var/vcap/packages/dea_next/buildpacks/bin/run:10:in'
FAILED
Server error, status code: 400, error code: 170001, message: Staging error: cannot get instances since staging failed
TIP: use 'cf logs jpu-henryhan --recent' for more information
The top error looks like you left off the -p <path_to_war> parameter when doing a push. If you just push a directory containing a WAR file, it will not be detected by the Java buildpack.
The tip provided in the output of your cf push request is relevant.
TIP: use 'cf logs jpu-henryhan --recent' for more information
Running that command will tail the log files produced during the staging process and let you see what error may have been raised. Often, it can be a missing dependency or a transient failure of some sort.
I just successfully deployed the sample using the "deploy to Bluemix" button and manually via the cf command line tool. Unless you changed the code, it is most likely that this error is a transient failure.
Run following command:
$ cf push jpu- -b https://github.com/cloudfoundry/java-buildpack --no-manifest --no-start -p PostgreSQLUpload.war
add the parameter to set the buildpack "-b https://github.com/cloudfoundry/java-buildpack"

Apache tomcat7 as windows service

I am trying to create a windows service for Apache tomcat 7.0.45.
( in windows version 7)
I executed this :
C:/tomcat7/bin> service install Mytomcat7
Windows service has been created. but it wont start and throws "specific server error code 4".
Can you please help with the steps to create windows service.
I had the same problem!
Found out, that the service.bat didn't configure the service the right way. If you enable the logging from your service starter:
Then you'll see in your loggs something like:
[2014-02-19 16:40:35] [error] ( javajni.c:863 ) [ 2636] FindClass org/apache/catalina/startup/Bootstrap failed
[2014-02-19 16:40:35] [debug] ( javajni.c:964 ) [ 2636] Java Worker thread finished org/apache/catalina/startup/Bootstrap:main with status=3
[2014-02-19 16:40:35] [error] ( prunsrv.c:1183) [ 5000] Failed to start Java
[2014-02-19 16:40:35] [error] ( prunsrv.c:1536) [ 5000] ServiceStart returned 4
You'll notice that there is some classpath problem with the starter. In fact that's the problem! Your service.bat didn't configure the service the right way:
Note: You can also choose "Use default" above "Java Virtual Machine" to use whatever JVM is defined in JAVA_HOME
You'll need to set the classpath correctly:
c:\webclient\apache-tomcat\bin\tomcat-juli.jar;c:\webclient\apache-tomcat\bin\tomcat-juli.jar;c:\webclient\apache-tomcat\bin\bootstrap.jar
In my case i "installed" tomcat at: c:\webclient\apache-tomcat replace that part with yours. In my case not even the Java VM was set.. I'm not shure whether this is a problem with the current versions of tomcat (and it's service.bat), or with some sort of permission problem on the windows server itself..
To solve this error perform the following steps:
Run the tomcat7w.exe monitor application found in <TOMCAT_HOME>/bin.Tomcat7w is a GUI application for monitoring and configuring Tomcat services. If you named your service Mytomcat7 you will need to rename this file to Mytomcat7.exe before running it
In the "Startup" tab change the value of "Mode" from jvm to Java
Do the same in the "Shutdown" tab
The easiest way to setup a tomcat Windows service is to use the Tomcat Windows Service Installer found on the same page as tomcat downloads.
http://tomcat.apache.org/download-70.cgi
However, if you are unable to use this installer. Then you can as you have try the above. The service created 'Mytomcat7' can be managed by the tomcat7w.exe file, after you rename it to 'Mytomcat7w.exe'.
Run the renamed file and you will be able to see all options for the service. The error you are seeing is likely related to an invalid JVM location or JVM mode not set to auto.
Details of settings found here:
http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html
I would just use the installer, it will make your life easier.
http://mirror.ox.ac.uk/sites/rsync.apache.org/tomcat/tomcat-7/v7.0.50/bin/apache-tomcat-7.0.50.exe

Categories