Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
10 of 10

Memory leak (SessionImpl) when updating index without transaction

Fixed

Description

Problem

We are observing thousands of already closed SessionImpl instances in memory. Some of them have references to large objects (via loadEvent or actionQueue), causing a significant memory consumption.

We are using the following pattern to update entities in the index:

This seems to be in line with https://docs.jboss.org/hibernate/search/5.5/reference/en-US/html_single/#search-batchindex-flushtoindexes except that we are not using a transaction. But obviously there is now a hard reference from PostTransactionWorkQueueSynchronization#transactionIdentifier to the SessionImpl instance, which will not be GCed any more:

According to the following comments, this should never happen:

Steps to reproduce

  1. Unpack Maven project

  1. , build and run MyExample.main() (in the IDE)
    -> Output

  2. Enter 's'

  3. Enter 'i'

  4. Perform GC, analyse heap dump (e.g. with Eclipse MAT)
    -> Now there should be 0 instances of SessionImpl, but instead there is 1 instance with the above Path2GC

Workaround

We found that one of the following approaches will solve the problem for us:

  • use a transaction while indexing

  • or call fullTextSession.flush() after fullTextSession.flushToIndexes()

Questions

But there are some questions left:

  1. Is the observed behavior expected or is it a bug that should be fixed?

  2. Is it forbidden to update the index outside a transaction?

  3. Is it required to use flush() after flushToIndexes()?

Attachments

2

Details

Assignee

Reporter

Sprint

Fix versions

Affects versions

Priority

Created May 17, 2021 at 7:58 PM
Updated October 18, 2021 at 8:21 AM
Resolved June 17, 2021 at 3:57 PM

Activity

Yoann RodièreJune 16, 2021 at 3:00 PM

Thanks again for the reproducer; I was able to write a test and to fix the problem. The patch will be applied to Hibernate Search 5.11.10.Final.

Yoann RodièreMay 18, 2021 at 7:08 AM

Hello,

Thanks for reporting this.

First, let me warn you that you are using a very old version of Hibernate Search that is no longer maintained.

That being said, it’s possible that this problem still occurs with Hibernate Search 5.10/5.11, and maybe even 6.0 (though that’s less likely), so we will have a look, and if possible fix the problem in those versions. We will not backport the fix to 5.5.

To answer your questions:

  1. I have to get a closer look to your reproducer to tell if it’s a bug or misuse.

  2. It is not forbidden to update the index outside a transaction, but it’s definitely not recommended. See for details of each mode (outside a transaction/within a transaction).

  3. Using flush() after flushToIndexes() is not normally required, but I’d have to check your particular use case.

Flag notifications