Replies: 2 comments 6 replies
-
Looks like you are using gRPC correct? Do you have an narrowed down example that causes the native image build error? |
Beta Was this translation helpful? Give feedback.
1 reply
-
The issue is with GraalVM and GCP modules. They need an extra information, see https://micronaut-projects.github.io/micronaut-gcp/latest/guide/#nativeImage. However, just tested it out with <profiles>
<profile>
<id>graalVM</id>
<activation>
<property>
<name>packaging</name>
<value>native-image</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>native-image-support</artifactId>
</dependency>
</dependencies>
</profile>
<profile>
<id>graalVM-docker</id>
<activation>
<property>
<name>packaging</name>
<value>docker-native</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>native-image-support</artifactId>
</dependency>
</dependencies>
</profile>
</profiles> to your pom.xml. And that should allow you to create a native docker image. |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
we are having a few services using Micronaut.
Environment
Our deployed setup relies on Google Cloud run, which simply put: is just a volatile container that is spawned when needed and shutdown if not used for a while.
There are a few aspects which slows down the first incoming request.
I cannot say specifically the timings of each step, but comparing to different implementations with javascript and golang, 1 is low in impact.
3 has the most impact, which is mitigable by the platform itself using "warm" instances or permanent cpu allocation.
Still 4 has impact of around 1-1.5s
We have figured out that some dependencies, like micronauts declarative http-client is using (probably dynamic proxies) creating objects at runtime, which slows down our first request.
Knowing these two conditions, there are a few options in mind:
a. Mitigate 3 by having warm instances and creating all known objects at startup time e.g. using StartupEvent and trigger an http request, which instanciates all needed objects of the http-client
b. using native-image
c. using micronaut-aot
native-approach
While the documentations of micronaut and graalvm is working in all tutorials, having actual code using dependencies leads to errors in compilation.
As far as i have understood, micronauts framework itself is supporting native images pretty well since it avoids stuff like reflections. The issues comes with depending libraries.
Since this question also could be set on each dependent project or graalvm itself, i am seeking for general advices on understanding the actual error messages.
As followed the dependencies and our current error message running
mvn package -Dpackaging=docker-native
Maven pom.xml
mvn package -Dpackaging=docker-native
AOT
I still don't understand the actual use of it. Is this a feasible way? I could not find comprehensive documentation on this.
Beta Was this translation helpful? Give feedback.
All reactions