[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-598) MassIndexer freezes when pool size is too low

[Adrien (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41906#action_41906 ] 

Adrien commented on HSEARCH-598:
--------------------------------

I have the same problem and here what I found : 

Using the mass indexer with 34 entities, it launch 34 BatchIndexingWorkspace. Even with threadsToLoadObjects(1) and threadsForSubsequentFetching(1), each BatchIndexingWorkspace take 3 connections (one for entity consumer, one for identy consumer and one for identity producer). So a total of 102 connections. The problem comes from the fact that if the identity consumer take the last connection first and then wait for its identity producer, the identity producer waits for a connection that will never be given back. Double lock.

One way to go around this problem would be not to launch the indexer for all the entity at the same time. To control the executor in BatchCoordinator.doBatchWork().

Any other idea ?

> MassIndexer freezes when pool size is too low
> ---------------------------------------------
>
>                 Key: HSEARCH-598
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-598
>             Project: Hibernate Search
>          Issue Type: Bug
>          Components: documentation, massindexer
>    Affects Versions: 3.2.1
>         Environment: Hibernate Core 3.5.4, PostgreSQL 8.4.4
>            Reporter: I D
>            Assignee: Sanne Grinovero
>             Fix For: 3.2.2, 3.4.0
>
>
> In our application we use db connection pooling at the servlet container level - Jetty instantiates a com.mchange.v2.c3p0.ComboPooledDataSource. We've disabled Hibernate's connection pooling to avoid multiple connection pools.
> Soon after starting to use MassIndexer we noticed that it SOMETIMES freezes during operation - startAndWait() just hangs indefinitely. After some experimentation, we realized that during this freeze the connection pool is maxed out and all the 15 connections (c3p0's default value for maxPoolSize is 15) are active.
> We therefore experimented with various values for maxPoolSize and found that 10 or less always seems to cause freezes, whereas 20 or more seems to work fine consistently. In between is a grey area, where the freeze occurs inconsistently (this grey area may of course extend to maxPoolSize<=10 and/or maxPoolSize>=20, since our tests only provide a partial statistical sample).
> If this is expected behavior, the minimal pool size / number of required connections should be well documented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira