[Hibernate-JIRA] Created: (HHH-7247) Bug on flushing context with modified non initialized lazy collection ( It works fine on hibernate 3.5.6 )
by Hood Wilson Gusso Silva (JIRA)
Bug on flushing context with modified non initialized lazy collection ( It works fine on hibernate 3.5.6 )
----------------------------------------------------------------------------------------------------------
Key: HHH-7247
URL: https://hibernate.onjira.com/browse/HHH-7247
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: This problem occurs on hibernate 3.3.2 and 3.3.1
( The latest JPA1 hibernate implementations I've found )
Reporter: Hood Wilson Gusso Silva
Attachments: hibernateTc1.zip
This is a quite trick problem that only occurs on modified lazy collections that aren't initialized
( Like when you do a add() operation without any previous size() or get() or toString() ... )
I think that it will be easier to show it by a commented source.
I made a little database (with only 3 simple tables to make possible to reproduce the error.) + a maven project
The maven project have 2 file called pom33.xml and pom35.xml so it's possible to easily see how the error occurs on 3.3.2 but not on 3.5.6
the script to recreate the problem is available within the project too.
BTW the source do a rollback ( So it won't change the database ).
If you want changes on db it will be necessary to change the rollback() to commit()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[Hibernate-JIRA] Created: (HSEARCH-1090) Hibernate search 4.* doesn't close open files
by Bostjan Lah (JIRA)
Hibernate search 4.* doesn't close open files
---------------------------------------------
Key: HSEARCH-1090
URL: https://hibernate.onjira.com/browse/HSEARCH-1090
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 4.1.0.Final, 4.0.0.Final
Environment: Hibernate ORM 4.1.2, H2 database
Reporter: Bostjan Lah
Attachments: testcase.zip
When running our application with Hibernate ORM 4.1.2 and Hibernate search 4.1.0 it very quickly uses all allowed open files. Increasing the limit just extends the time that it takes to consume all. This does not happen when running with Hibernate ORM 3.6 and Hibernate search 3.4.
I have created a small testcase. When I run it here (Linux) I get to about 500 open deleted files (to count I use lsof -p xxx|grep -c deleted) within 10 minutes of starting it. It does not matter what filesystem access type I use (simple, nio, mmap). Mmap just tends to hide the issue better and keeps increasing process's virtual mem size. With nio it's very simple to check how many deleted files are still open. Normally within about 20min the process runs out of it's 1024 allowed open files.
I have tried playing with other search settings but none of them have helped so far.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[Hibernate-JIRA] Created: (HSEARCH-1115) Failure to load Analyzer class when deployed into AS7
by Randall Hauch (JIRA)
Failure to load Analyzer class when deployed into AS7
-----------------------------------------------------
Key: HSEARCH-1115
URL: https://hibernate.onjira.com/browse/HSEARCH-1115
Project: Hibernate Search
Issue Type: Bug
Reporter: Randall Hauch
Specifying an analyzer class via the "hibernate.search.analyzer" configuration property results in an exception when initializing the Hibernate Search engine within the AS7 environment:
{code}
Caused by: org.hibernate.search.SearchException: Analyzer found with an unknown definition: org.apache.lucene.analysis.standard.StandardAnalyzer
at org.hibernate.search.impl.ConfigContext.initLazyAnalyzers(ConfigContext.java:252)
at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:434)
at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:221)
at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:145)
...
{code}
Even setting the "hibernate.search.analyzer" property to "org.apache.lucene.analysis.standard.StandardAnalyzer" (which happens to be the default if no analyzer class is specified) will also fail.
I believe this exception is occurring within the AS7 module class loading environment because during initialization of the Hibernate Search engine (e.g., {{SearchFactoryBuilder.buildSearchFactory}}), the {{ConfigContext.initAnalyzer}} method is called and uses Hibernate's {{ReflectionHelper}} class to try to load the analyzer class (see [this code|https://github.com/hibernate/hibernate-search/blob/4.1.0.Final/hiber...]). The {{ReflectionHelper}} uses the Thread context class loader to try to find the class or (if that fails) the class's class loader; neither of these work in AS7's module system, unless the JARs with the analyzer are defined within the "org.hibernate" module.
A better solution needs to be found in order for the analyzer class to be specified. Ideally, the solution should be flexible enough so that any AS7 subsystem that uses Hibernate Search can specify the analyzer classname and module.
See [this forum discussion|https://forum.hibernate.org/viewtopic.php?f=9&t=1015297&sid=fe...] for discussion and additional context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months