Open siddjain opened 2 years ago
tsegismont
commented
2 years ago Jib puts libraries in a separate image layer, perhaps that's related to the time spent scanning the classpath. Although more than a minute to do this sounds very weird.
Perhaps there's an issue in the persistence.xml file. Or with Coretto in this environment.
siddjain
commented
2 years ago we are using the same persistence.xml as in this repo and overriding some fields using below code:
var props = new HashMap<String, String>();
fetch("javax.persistence.jdbc.url", props);
fetch("javax.persistence.jdbc.password", props);
fetch("javax.persistence.jdbc.user", props);
emf = Persistence
.createEntityManagerFactory("pg-demo", props)
.unwrap(Mutiny.SessionFactory.class);we also tried using eclipse temurin but the same issue persists. One thing we have noticed is that the callstack is not identical everytime but each time the thread is blocked in the call to:
Persistence.createEntityManagerFactoryI did not understand this:
Jib puts libraries in a separate image layer, perhaps that's related to the time spent scanning the classpath.
we also changed the code like this and added a try/catch block:
Uni<Void> startHibernate = Uni.createFrom().deferred(() -> {
try {
var props = new HashMap<String, String>();
fetch("javax.persistence.jdbc.url", props);
fetch("javax.persistence.jdbc.password", props);
fetch("javax.persistence.jdbc.user", props);
emf = Persistence
.createEntityManagerFactory("pg-demo", props)
.unwrap(Mutiny.SessionFactory.class);
return Uni.createFrom().voidItem();
} catch (Exception e) {
return Uni.createFrom().failure(e);
}
});Question for you: Without the try/catch block, if there is an exception in Persistence.createEntityManagerFactory, it will not propagate to main program and will be lost. is that correct?
tsegismont
commented
2 years ago I did not understand this:
Jib puts libraries in a separate image layer, perhaps that's related to the time spent scanning the classpath.
See https://github.com/GoogleContainerTools/jib#how-jib-works
Question for you: Without the
try/catchblock, if there is an exception inPersistence.createEntityManagerFactory, it will not propagate to main program and will be lost. is that correct?
I don't believe so, deferred should catch the exception and report it to the subscriber.
siddjain
commented
2 years ago any tips you can provide to help us debug? so far it seems then there is no exception, the thread is really blocked. we are unable to capture a thread dump because its running in cloud run environment.
tsegismont
commented
2 years ago Have you tried the debug mode? https://cloud.google.com/code/docs/intellij/debug-service
Hello,
we tried using this sample to learn vert.x. we can run it locally but when we deploy on google cloud run we get an exception:
The full log is below:
To adapt the sample for google cloud run, we have made following modifications:
and add
modify the Java code and persistence.xml accordingly
We use the Maven Jib plugin to build a Docker image that is required by google cloud run. The base image we use is
amazoncorretto:17.0.4I understand people here might not be able to provide help as I think this has something to do with the Docker image built by Jib but I was wondering if someone can at least tell how to modify the code in MainVerticle so that we can see the actual exception and program should halt instead of getting a
io.vertx.core.VertxException: Thread blocked. It looks like the original exception has been lost and does not propagate to the main thread.