Hibernate Search is not the one throwing the exception. As you can see here, the error occurs while fetching results from Hibernate ORM:
|INFO | jvm 1 | 2018/09/28 16:58:11 | |at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1896)|
|---|---|
|INFO | jvm 1 | 2018/09/28 16:58:11 | |at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:366)|
|INFO | jvm 1 | 2018/09/28 16:58:11 | |at org.hibernate.search.batchindexing.impl.IdentifierConsumerDocumentProducer.loadList(IdentifierConsumerDocumentProducer.java:174)|
And as you can see here, the error is caused by some problem in the bytecode enhancement:
INFO | jvm 1 | 2018/09/28 16:58:11 | Caused by: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:582)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:574)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection.access$200(AbstractPersistentCollection.java:55)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:165)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:146)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:247)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:145)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.collection.internal.PersistentSet.size(PersistentSet.java:143)
INFO | jvm 1 | 2018/09/28 16:58:11 | at java.util.AbstractSet.equals(AbstractSet.java:92)
INFO | jvm 1 | 2018/09/28 16:58:11 | at org.hibernate.internal.util.compare.EqualsHelper.areEqual(EqualsHelper.java:53)
INFO | jvm 1 | 2018/09/28 16:58:11 | at com.csc.pt.svc.data.to.Basclt0100TO.$$_hibernate_write_basclt0300toList(Basclt0100TO.java)
INFO | jvm 1 | 2018/09/28 16:58:11 | ... 49 more
I
If I was you, I would try to reproduce the problem with a basic Hibernate ORM query that tries to load entity Basclt0100TO. There is very probably either a mapping issue, or a bug in Hibernate ORM. In either case, getting rid of some complexity can only help you to debug it.
As side notes…
First, you’re using outdated versions of Hibernate Search an Hibernate ORM; the latest version of Hibernate Search is 5.10.4.Final and the latest version of Hibernate ORM is 5.3.6.Final. Switching to those versions could eliminate your problem, as several bugs have been fixed, in particular when it comes to bytecode enhancement.
Second, even though it’s unrelated to your problem, Hibernate Search 5 is not designed to work well with Elasticsearch 6. From the documentation:
Hibernate Search expects an Elasticsearch cluster running version 2.x or 5.x.
You probably also got a warning in your logs about that.
Now, as long as ES6 is backward-compatible with ES5, it should work, but since it’s a major version, there’s no guarantee. In particular Elasticsearch 6 does not allow to map multiple types in a single index, so you should avoid doing that.