[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: stacktrace.txt ThrashIndex.java > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: IndexWriter.patch I found this: http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/or g/apache/lucene/store/NativeFSLockFactory.html And so I made the attached patch which seems to run at least 100x longer than without. - will > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: IndexWriter2.patch the attached patch adds a param to SolrIndexConfig called useNativeLocks. the default is false which will keeps with the existing design using SimpleFSLockFactory. if people think we should allow fully pluggable locking mechanisms i'm game but i wasn't quite sure how to tackle that problem. as for testing, i wasn't quite sure how to run tests to ensure that the locks were working beyond some basic println's (which passed). if anyone has good ideas i'm all ears. - will > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, > ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-240: -- Attachment: IndexWriter2.patch This is a variation on Will's IndexWriter2.patch that replaces the "useNativeLocks" boolean config option with a string config option allowing people to pick any of the 4 built in Lucene lock factories. (i'd been meaning to try and write a "LockFactoryFactory" to allow people to specify any arbitrary LockFactory impl as a plugin, but it seemed like overkill -- having Will's useNativeLocks option didn't preclude adding something like that later, but recent comments reminded me that for the majority of SOlr users, the "NoLockFactory" would actually be perfectly fine since Solr only ever opens one IndexWriter at a time) so this patch provides a little bit more flexibility then the previous one, without going whole-hog to a FactoryFactory/plugin model. It should be noted that I left the hardcoded default in the code in to be SimpleFSLockFactory but i set the "example" default to be NoLockFactory with a comment that that should be find for any Solr user not modifying the index externally to Solr. comments? > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, > IndexWriter2.patch, stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-240: -- Attachment: IndexWriter2.patch good point about recommending 'single' in the event of concurrency bugs. i've never really looked at the internals of the LockFactories so i'm going to punt on the subclass idea for now (i like it i just don't have time to do it) but we can always redefine "single" later. (i'll open another bug if we're okay with committing this new patch as is) revised patch just changes the wording and suggested value in solrconfig.xml objections? > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, > IndexWriter2.patch, IndexWriter2.patch, stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
>comments? Hooray, and very cool. I didn't know you only needed a locking mechanism if you only have multiple index writers so the use of NoLock by default makes perfect sense. A quick stability update: Since I first submitted the patch ~2 months ago we've had 0 lockups with it running in all our test environments. - will
Re: [jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
On 7/13/07, Will Johnson <[EMAIL PROTECTED]> wrote: Hooray, and very cool. I didn't know you only needed a locking mechanism if you only have multiple index writers so the use of NoLock by default makes perfect sense. For Lucene, you do (did.. before lockless commits pach) need locking (a read lock) even to open an index with a reader. The write lock is still also needed to avoid a reader changing the index via deletion at the same time a writer is. Solr coordinates this at a higher level, hence it's not really needed. -Yonik
