Spring Boot 2.3.0 won't start with hibernate.search.FieldBridge annotation in use #25111
Assignees
Labels
in: data
Issues in data modules (jdbc, orm, oxm, tx)
status: invalid
An issue that we don't feel is valid
Comments
knoobie
changed the title
|
Thanks for the sample. The problem is caused by Spring Boot 2.3 moving to bootstrapping Hibernate asynchronously by default. When Hibernate Search is involved, its bootstrapping results in a call back into the bean factory via spring:
data:
jpa:
repositories:
bootstrap_mode: default |
|
Thanks @wilkinsona! |
spring-projects-issues
added
the
status: waiting-for-triage
|
Hi, Hibernate Search developer here. Maybe this can shed some light on the problem: From what I understand (I might be wrong), Spring doesn't initialize Hibernate ORM lazily; it just instructs Hibernate ORM to resolve beans lazily, while performing the whole bootstrap process eagerly. That's possible for Hibernate ORM because the beans (converters, ...) are only used at runtime. Hibernate Search, on the other hand, retrieves "bridges" through Spring. The "bridges" provide metadata that is needed at bootstrap, and thus they must be resolved eagerly at startup, so that the bootstrap process completes. Thus the "deferred" bootstrap mode in Spring cannot currently work out of the box in Hibernate Search. There is a feature in Hibernate Search that defers the whole bootstrap process of Hibernate Search to a later time, but I'm not sure it would help, as a) Spring doesn't include any integration code specific to Hibernate Search right now (and I'm not sure you'll want that) and b) that feature only delays the bootstrap, it does not make it "lazy". See |
|
The problem doesn't appear to be limited to apps that use Hibernate search. @ctmay4 shared a thread dump on the Spring Boot issue that switched the default to deferred which shows Hibernate ORM code calling back into the bean factory via |
|
Yes, it's the same for us. This is happening randomly. main thread which waits for the Future to complete task-1 thread executing the Future The If we switch to DEFAULT mode, it works fine as before. |
|
Once we have a fix for this issue, testing it against https://github.com/hgarus/entitylistener-deadlock is in order as it's yet another occurence of this issue. |
|
Adding |
|
It seems you can't inject anything into entity listeners when using |
Yes it does, as does setting Both cause the creation of the EntityManagerFactory in Spring-Boot changed the default for Somewhat interestingly |
|
Encountered the same issue, hangs sometimes during startup while trying to inject |
|
@matf using deferred initialization for JPA means that you shouldn't be touching the JPA infrastructure on startup. It's not obvious why that is which is why we've decided to switch back to the default mode in Spring Boot, see spring-projects/spring-boot#24249.
If that's the regular auto-configuration, it shouldn't do that per spring-projects/spring-boot#23740. |
|
If there is nothing that we can do about this from the core JPA support side, let's rather close this issue. |
jhoeller
added
status: invalid
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the annotation
org.hibernate.search.FieldBridgein a spring boot 2.3.0 project resulting in a "dead-lock". The application won't start. Removing the annotation fixes it.Example (Java 8):
https://github.com/knoobie/spring-2-3-fieldbridge
mvn clean install-> tests are workingmvn clean install->@FieldBridgeline is removed fromAnswerthe application is running again, but the test fails (as expected).Thread dump:
The text was updated successfully, but these errors were encountered: