[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea updated HSEARCH-513: ---------------------------------- Attachment: AllLibsExceptSpringAndHibernate.zip I've attached all the necessary libs except for Spring 3.0.2 and Hibernate 3.5.1-Final (hibernate3.jar) because I would have exceeded the upload size. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- Hi, I can take a look at this as I've got the spring test framework for this set up (if no one has any objections) -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Emmanuel Bernard commented on HSEARCH-513: ------------------------------------------ Where are we at on this? This is the only issue blocking 3.2 final. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- Posted recommendations to user on the forum. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Hardy Ferentschik commented on HSEARCH-513: ------------------------------------------- Hi Florin, I also looked at your test case, but I am not quite sure what to do with it. We really would need a [SSCCE|http://www.pscode.org/sscce.html] example or at least some instructions on how to run your test case. As far as I can see there is neither a build file (ant or maven or whatever) nor any sort of unit test class. In the best case you would provide some minimal configuration triggering the behavior by running some sort of unit test. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- I wasn't too sure about the object model as well but when i used the model and performed an insert 1000 times (in a single transaction) and didn't get any exceptions or strange behaviour (tried both lucene and jms backend). Apart from the model which might be an issue, i think there is an issue with the aop pointcut definition. I wouldn't be surprised if it's Spring managed tx causing a problem (had so many issues when working on my last project). -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Hardy Ferentschik commented on HSEARCH-513: ------------------------------------------- I cannot speak for the AOP part. When I used Spring in some of my projects I always used declarative transaction demarcation (annotations). Using the AOP approach might create too many transactions. Some log output could maybe help. Not only from the Hibernate part, but also from Spring. Where and when and how many transactions get used. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- I have run a test using the input file provided and the the GedcomManagerTest class and all works as expected. I don't see a degradation of performance. The average time it takes to save each batch is approximately 52ms. I am not using the aop pointcut definition but springs declarative approach. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- Performed the test using MySQL and the average time for batch save is 176 milliseconds, ran this test 10 time with the same outcome. Using Mac OS 10.6.3, MySQL Java Connector 5.1.9, Spring 3.0.2, Java 1.6.0_17. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- I reproduced the whole scenario again. Here's what I did: 1) created a test project from the sources found in HibernateSearchJira.zip (using IntellijIdea under Windows) 2) imported all the libs from AllLibsExceptSpringAndHibernate.zip, SpringAndHibernateLibs.zip and hibernate3.jar (which I forgot to add initially) 2) created the DB using schema.sql 3) ran GedcomManagerTests.testSavePeople() from Intellij (with these memory settings: -Xms256m -Xmx1024m -XX:MaxPermSize=120m -ea) and obtained the attached output. Here is a sample of the output of a second run: Saving batch number 250 Finished saving batch number 250in 203millis Saving batch number 251 Finished saving batch number 251in 203millis Saving batch number 252 Finished saving batch number 252in 219millis Saving batch number 253 Finished saving batch number 253in 156millis Saving batch number 254 Finished saving batch number 254in 453millis Saving batch number 255 Finished saving batch number 255in 1265millis Saving batch number 256 Finished saving batch number 256in 10297millis Saving batch number 257 Finished saving batch number 257in 281millis Saving batch number 258 Finished saving batch number 258in 1125millis Saving batch number 259 Finished saving batch number 259in 172millis Saving batch number 260 Finished saving batch number 260in 375millis Saving batch number 261 Finished saving batch number 261in 672millis Saving batch number 262 Finished saving batch number 262in 125millis Saving batch number 263 Finished saving batch number 263in 219millis Saving batch number 264 Finished saving batch number 264in 312millis Saving batch number 265 Finished saving batch number 265in 188millis Saving batch number 266 Finished saving batch number 266in 250millis Saving batch number 267 Finished saving batch number 267in 219millis Saving batch number 268 Finished saving batch number 268in 672millis Saving batch number 269 Finished saving batch number 269in 250millis Saving batch number 270 Finished saving batch number 270in 421millis Saving batch number 271 Finished saving batch number 271in 297millis Saving batch number 272 Finished saving batch number 272in 328millis Saving batch number 273 Finished saving batch number 273in 73141millis Saving batch number 274 Finished saving batch number 274in 141millis Saving batch number 275 Finished saving batch number 275in 312millis Saving batch number 276 Finished saving batch number 276in 719millis Saving batch number 277 Finished saving batch number 277in 328millis Saving batch number 278 Finished saving batch number 278in 219millis Saving batch number 279 Finished saving batch number 279in 33969millis Saving batch number 280 Finished saving batch number 280in 234millis Saving batch number 281 Finished saving batch number 281in 297millis Saving batch number 282 Finished saving batch number 282in 140millis Saving batch number 283 Finished saving batch number 283in 141millis Saving batch number 284 Finished saving batch number 284in 188millis Saving batch number 285 Finished saving batch number 285in 312millis Saving batch number 286 Finished saving batch number 286in 297millis Saving batch number 287 Finished saving batch number 287in 12687millis Saving batch number 288 Finished saving batch number 288in 49625millis Saving batch number 289 Finished saving batch number 289in 2282millis Saving batch number 290 Finished saving batch number 290in 984millis Saving batch number 291 Finished saving batch number 291in 2344millis Saving batch number 292 Finished saving batch number 292in 30203millis Saving batch number 293 Finished saving batch number 293in 391millis Saving batch number 294 Finished saving batch number 294in 203millis Saving batch number 295 Finished saving batch number 295in 234millis Saving batch number 296 Finished saving batch number 296in 10344millis Saving batch number 297 Finished saving batch number 297in 140millis Saving batch number 298 Finished saving batch number 298in 266millis Saving batch number 299 Finished saving batch number 299in 30719millis Saving batch number 300 Finished saving batch number 300in 140millis Saving batch number 301 Finished saving batch number 301in 188millis Saving batch number 302 Finished saving batch number 302in 141millis Saving batch number 303 Finished saving batch number 303in 343millis Saving batch number 304 Finished saving batch number 304in 1750millis Saving batch number 305 Finished saving batch number 305in 1219millis Saving batch number 306 Finished saving batch number 306in 234millis Saving batch number 307 Finished saving batch number 307in 1797millis Saving batch number 308 Finished saving batch number 308in 297millis Saving batch number 309 Finished saving batch number 309in 141millis Saving batch number 310 Finished saving batch number 310in 4281millis Saving batch number 311 Finished saving batch number 311in 625millis Saving batch number 312 Finished saving batch number 312in 219millis Saving batch number 313 Finished saving batch number 313in 1094millis Saving batch number 314 Finished saving batch number 314in 203millis Saving batch number 315 Finished saving batch number 315in 312millis Saving batch number 316 Finished saving batch number 316in 453millis Saving batch number 317 Finished saving batch number 317in 891millis Saving batch number 318 -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- I've attached my output from my test. I'll look at using your entire project. It's very strange that you run out of memory as i've run my tests more than once without that. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea updated HSEARCH-513: ---------------------------------- Attachment: build.xml Ant build file for running the tests. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- Hi I loaded your project and can confirm that the timings for batch inserts are very poor. I am using H2 and getting poor results. Strange when i compare my code using your domain model I don't get the same performance degradation. I will investigate and get back to you. sorry for the delay with this again! -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Amin Mohammed-Coleman commented on HSEARCH-513: ----------------------------------------------- Hi I've uploaded my version of the project which runs the same test as yours using H2. The test in the project pass and the average time for batch insert is around 100ms. Can you check this project out and run the test and check the mapping and domain model? I'll carry on looking at your one. It's a maven project so just import into IntelliJ. The test you want to run is GedcomManagerTest. Thanks -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi Amin, Today I tried to see why your project has such good insert times per batch and mine doesn't. Well, first I am using a FSDirectoryProvider and you are using a RAMDirectoryProvider. This causes all of your batch insert times to be 4-5 times faster than mine (this is just an estimate, didn't look much into this). But this still doesn't solve my issue, namely that some of the batches take a very long time to be saved. Even using the RAMDirectoryProvider. What does make a difference though are the equals/hashCode methods in the Person, Event and ParentOfEvent classes. If I comment those out in your project, I can reproduce the long insert times (the first one being for batch 273). Similarly, if I implement the equals/hashCode in my project, I do not experience those long times. So overriding equals/hashCode for the indexed entities seems to solve the problem. Is this a bug? Must we override equals/hashCode in all our indexed entities? Not that this is a problem, just that I didn't know it was that important. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi Amin, While dealing with other issues that I had with hibernate search I tried to see if implementing equals and hashCode would solve those issues. I implemented equals the way you did and I found out that not all the entities are being indexed. Lets say we have a Person which has a set of Name(s). If we use equals the way you did, only comparing the ids, then all the non persisted names are equal to each other because their ids are null. Thus if we create a Person and add 20 names to its names set, in the end, the names set will contain only one name. This is obviously a problem, both for the application logic, as only 1 name is saved instead of 20, and for the hibernate searching as only one name is being indexed instead of 20. Here is a relevant article: http://community.jboss.org/wiki/EqualsandHashCode Taking this into account, I guess that why equals and hashCode solve the batch time problem is simply because hibernate search does not index all the relationships of an entity. So instead of solving the bug, this only hides it. I did not verify this but this is what I think it happens. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi Amin, In my previous post the Person-Name scenario was just an example that I used to underline the fact that equals and hashCode would just cause hibernate search to skip some of the entities and that was the actual thing that "solved" our bug. The Name object is not present in the code that I added to this jira issue. The number of people that are added in your project and mine is 7924 (the last id in the test file is "0 @I7924@ INDI"). So the number of documents should match this number. If there are less, that means that not all people are indexed (most likely due to the equals method). -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi Sanne, We are not using annotations and still get this problem. In the issue that you linked to, jlage implies that he experienced the slowdown only after switching to annotations. And our problem is strictly a problem of long slowdowns and freezes when we save batches of entities. I don't know if this is the same problem as jlage's and to me it looks as a different issue. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi guys, Can you give me any updates on this issue? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Emmanuel Bernard resolved HSEARCH-513. -------------------------------------- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.3.0.CR1 MArked as resolved, no further user feedback. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi guys, Sorry for the VERY late response but we had some other problems to deal with on our project. Emmanuel, I've used the snapshot lib you suggested but that didn't change anything. The indexing times are not improved. I've also run tests using the latest version of hibernate: 3.6.0.Final, hibernate-search 3.3.0.CR1, lucene-corep-3.0.2, lucene-analyzers-3.0.2, lucene-snowball-2.9.3, solr-core-1.4.1, solr-solrj-1.4.1 and I get the exact behaviour. No improvement in indexing times. This behaviour prevents me from indexing object associations in my project. What should I do? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea edited comment on HSEARCH-513 at 11/20/10 7:12 PM: ----------------------------------------------------------------- Hi guys, Sorry for the VERY late response but I had some other problems to deal with on my project. Emmanuel, I've used the snapshot lib you suggested but that didn't change anything. The indexing times are not improved. I've also run tests using the latest version of hibernate: 3.6.0.Final, hibernate-search 3.3.0.CR1, lucene-corep-3.0.2, lucene-analyzers-3.0.2, lucene-snowball-2.9.3, solr-core-1.4.1, solr-solrj-1.4.1 and I get the exact behaviour. No improvement in indexing times. This behaviour prevents me from indexing object associations in my project. What should I do? was (Author: eborix13): Hi guys, Sorry for the VERY late response but I had some other problems to deal with on a project. Emmanuel, I've used the snapshot lib you suggested but that didn't change anything. The indexing times are not improved. I've also run tests using the latest version of hibernate: 3.6.0.Final, hibernate-search 3.3.0.CR1, lucene-corep-3.0.2, lucene-analyzers-3.0.2, lucene-snowball-2.9.3, solr-core-1.4.1, solr-solrj-1.4.1 and I get the exact behaviour. No improvement in indexing times. This behaviour prevents me from indexing object associations in my project. What should I do? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- Hi Hardy, Thanks for the tip. I changed the dependencies but I actually wasn't using solr at all. In this small sample project I don't define any Analyzers or any Tokenizers. So the problem still remains. Thanks anyway. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Emmanuel Bernard commented on HSEARCH-513: ------------------------------------------ I was never able to reproduce it personally. Amin, do you have a reproducible setup? Have you investigated further? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- I've tried to profile the indexing test and if it's helpful to you guys I've uploaded some profiler snapshots. I've used YourKit Java Profiler so you can open it with that. From what I can figure out, most of the indexing times are spent in the org.hibernate.search.backend.impl.BatchedQueueingProcessor's.optimize(List) method. More exactly in the following lines: List<LuceneWork> result = new ArrayList<LuceneWork>( size - toDelete.size() ); for ( int index = 0 ; index < size; index++ ) { if ( ! toDelete.contains( index ) ) { result.add( luceneQueue.get( index ) ); } } -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero commented on HSEARCH-513: ----------------------------------------- Hi Florin, great this snapshot is very useful. btw what's the relation between Florin, mueller, eborix13 (last two on the forum), are you all the same person or just working together? I'm getting confused. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Scott Mueller commented on HSEARCH-513: --------------------------------------- Hi Sanne, I am mueller. Florin is eborix13. We work together. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Florin Haizea commented on HSEARCH-513: --------------------------------------- I've added a maven version of the project. After installing, you can generate the DB schema by executing the following 2 commands in the model directory: mvn hibernate3:hbm2ddl and mvn sql:execute. Then execute mvn test in the root directory. The indexing times will be printed while the test executes. Unfortunately the only way I can provide a complex enough scenario is to read all the Person objects and the relationships between them from a file. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero reopened HSEARCH-513: ------------------------------------- Assignee: Sanne Grinovero we have a means to reproduce it now. Thank you! -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Svyatoslav Reyentenko commented on HSEARCH-513: ----------------------------------------------- Thank you very much. I can confirm significact test speedup. However, from time to time we get occasional ConcurrentModificationException during test. This is a last part of stack trace: aused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$EntryIterator.next(HashMap.java:834) at java.util.HashMap$EntryIterator.next(HashMap.java:832) at org.hibernate.search.engine.WorkPlan$PerClassWork.processContainedIn(WorkPlan.java:135) at org.hibernate.search.engine.WorkPlan.processContainedIn(WorkPlan.java:70) at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:150) It was tested with and without async work execution setting. If you need, you can find a slightly modified Florin test at: https://github.com/rsvato/florin-test -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero commented on HSEARCH-513: ----------------------------------------- Hi Svyatoslav, thank you for the quick feedback. No I won't ignore your stacktrace, you're right that's a silly mistake in my code and I just fixed it, it's on github. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero updated HSEARCH-513: ------------------------------------ Issue Type: Bug (was: Improvement) Summary: Experiencing long delays when indexing entities saved in different transactions (was: Optimize engine to handle transactions having a large set of changes) reverting change in title, I'll have it point to other issues. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero commented on HSEARCH-513: ----------------------------------------- Hi Svyatoslav, thank you if you want to contribute on any other issue or suggest improvements that's very welcome, but also the kind of feedback you're providing is appreciated. About this issue, I've opened HSEARCH-638 as a continuation to this one: your long delays are caused by 1)inefficient use of data structure 2)HSEARCH-638 and 3)HSEARCH-570 With the current change we solve 1 and 3, but I have to postpone 2) to next version. I can't make such a big change for 3.3 as we need to get this stable and release soon, but I understand your use case is affected by that. Could you tell me if the improvements reached so far are good enough at the moment to keep the speed at acceptable levels, or is further improvement needed in short time? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513?pag... ] Sanne Grinovero commented on HSEARCH-513: ----------------------------------------- I'm glad to hear that. Emmanuel is reviewing my patch (and found a little problem already); this is likely to be included in a release planned for end of next week. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira