Hide Forgot
project_key: SOA I am running a simple test that does fulltext search in the default EDS repository. The code is executed inside the container. For the first time the test passes without any issues. If test is executed for the second time then it blocks indefinitely when in tries to access repository. There is no such issue with other searches supported with ModeShape. The log file contains First run 11:53:27,940 INFO [STDOUT] [TestNG] Running: InContainer 11:53:27,954 INFO [STDOUT] Retrieving server repository: eds 11:53:28,363 INFO [STDOUT] Retrieving server repository: eds 11:53:28,469 INFO [STDOUT] /queryNode {query_property=testvalue, jcr:primaryType=nt:unstructured, } 11:53:28,480 INFO [STDOUT] =============================================== InContainer Total tests run: 1, Failures: 0, Skips: 0 =============================================== Second run 11:53:35,802 INFO [STDOUT] [TestNG] Running: InContainer 11:53:35,802 INFO [STDOUT] Retrieving server repository: eds The code is attached, configuration file is pristine SOA-P.
Attachment: Added: modeshape-fts.tar
Link: Added: This issue Cloned to SOA-3491
Link: Added: This issue Cloned to SOA-3492
Link: Removed: This issue Cloned to MODE-1280
Attached a proposed (and as of yet untested) patch JAR that can be applied to ER5. As noted in MODE-1279 (the project issue), a unit test was created to replicate this issue, and the proposed fix does make that unit test pass. This JAR is based upon those changes.
Attachment: Added: modeshape-soa-3486-patch.jar
Not easily reporduced. Not in 5.2
Jirka - can you confirm that to recreate this bug you simply run the fulltext search twice? Thx!
As you can see in the description -it is very easy to reproduce. It is enough to call search twice.
I tried the patch and I can confirm that the issue is fixed.
Horia Chiorean <hchiorea> made a comment on jira MODE-1279 Fixed repository blocking after performing a full-text search multiple times. The cause of the problem was the explicit synchronization around the Lucene search processor and engine. The fix was part of the https://github.com/ModeShape/modeshape/pull/207 pull request, which basically removed explicit synchronization around the LuceneSearchProcessor and Engine. In addition: * the Lucene version was updated from 3.1.0 to 3.4.0 * the LuceneSearchSession was updated to avoid the possible loss of content when indexing the same content in the same workspace from multiple threads Run both the unit tests and integration tests a couple of time without any "apparent" deadlock.
Horia Chiorean <hchiorea> made a comment on jira MODE-1279 Fixed repository blocking after performing a full-text search multiple times. The cause of the problem was the explicit synchronization around the Lucene search processor and engine. The fix was part of the https://github.com/ModeShape/modeshape/pull/207 pull request, which basically removed explicit synchronization around the LuceneSearchProcessor and Engine. In addition: * the Lucene version was updated from 3.1.0 to 3.4.0 * the LuceneSearchSession was updated to avoid the possible loss of content when indexing the same content in the same workspace from multiple threads. Lucene's IndexWriter class maintains internally a write lock, so using multiple IndexWriter instances concurrenty, for the same dir, couldn't work. Ran both the unit tests and integration tests a couple of time without any "apparent" deadlock.
Horia Chiorean <hchiorea> made a comment on jira MODE-1279 Fixed repository blocking after performing a full-text search multiple times. The cause of the problem was the explicit synchronization around the Lucene search processor and engine. The fix was part of the https://github.com/ModeShape/modeshape/pull/207 pull request, which basically removed explicit synchronization around the LuceneSearchProcessor and Engine. In addition: * the Lucene version was updated from 3.1.0 to 3.4.0 * the LuceneSearchSession was updated to avoid the possible loss of content when indexing the same content in the same workspace from multiple threads. Lucene's IndexWriter class maintains internally a write lock, so using multiple IndexWriter instances concurrenty, for the same dir, couldn't work. Ran both the unit tests and integration tests a couple of times without any "apparent" deadlock.
Randall Hauch <rhauch> made a comment on jira MODE-1279 Merged into the 'master' branch.
Issue has been fixed in 2.8
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: An error occurred when a full text search was performed in the default EDS repository. Access to the repository became blocked after performing these searches. The cause of the problem was the explicit synchronization around the Lucene search processor and engine. This has now been rectified and full text searches can be performed without the repository locking up.
Verified in ER5
Randall Hauch <rhauch> updated the status of jira MODE-1279 to Closed