Hello Patrice Oms,

Thanks for your report. Could you please give us the reference of the previous ticket you are mentioning?

From the screen captures you gave us, I can see indeed that a "Hibernate Search sync consumer thread" is waiting. However, these threads, as their names indicate, are consumers, and expect input so that they can work on it. So the fact they are waiting is probably not the cause of your problem, but rather the symptom: something that is supposed to create the input is not creating the input.

What's more interesting is the "Hibernate Search: entityloader-1" thread. This thread is in monitor status (read: blocked, waiting for synchronization). What's more, this thread is executing some of your own code: the MessageFieldBridge class, the set() method. The thread is actually blocking while trying to retrieve a Spring Bean.

Could you confirm that you are not trying to retrieve a spring bean each time the MessageFieldBridge.set is called? For example by calling ApplicationContext.getBean()? You must realize that MessageFieldBridge.set is in the hot path of the indexing code, so calling potentially costly operations such as ApplicationContext.getBean() inside this method could potentially slow down the indexing process to such an extent that it would seem to stop. To solve that, you should cache the bean somehow (for instance add a private volatile MyBean myBean field to your bridge, and replace your current code (applicationContext.getBean(...).doSomething()) with something like:

if ( myBean == null ) {
  myBean = applicationContext.getBean( ... );
}
myBean.doSomething();