Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build checkJunitPresence: compile-common: [mkdir] Created dir: /tmp/apache-solr-nightly/build/common [javac] Compiling 25 source files to /tmp/apache-solr-nightly/build/common [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/common/params/DisMaxParams.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/core [javac] Compiling 213 source files to /tmp/apache-solr-nightly/build/core [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj-core: [mkdir] Created dir: /tmp/apache-solr-nightly/build/client/solrj [javac] Compiling 21 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compile-solrj: [javac] Compiling 2 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/embedded/JettySolrRunner.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 58 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 24, Failures: 0, Errors: 0, Time elapsed: 29.212 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.231 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 12.133 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.562 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.593 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.983 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.049 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.073 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.045 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.073 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.056 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.059 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.061 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.046 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.075 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.046 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 12.991 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.05 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.09 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.034 sec
Hudson build is back to normal: Solr-Nightly #154
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/154/changes
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515888 ] Otis Gospodnetic commented on SOLR-215: --- Ryan e Henri: 1. Re TokenizerFactory - what will break with this change? Is the fear that people implemented this interface in their Solr apps and this change will break their implementations, or something else? 2. So can SolrUpdateServlet get axed, so SolrInit can be eliminated? If we can resolve these two, it sounds like we can commit this patch and then work on the rest. Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-215.patch, solr-215.patch, solr-215.patch, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch, solr-trunk-542847.patch, solr-trunk-src.patch WHAT: As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index. This patch is intended to allow multiple cores in Solr which also brings multiple indexes capability. The patch file to grab is solr-215.patch.zip (see MISC session below). WHY: The current Solr practical wisdom is that one schema - thus one index - is most likely to accomodate your indexing needs, using a filter to segregate documents if needed. If you really need multiple indexes, deploy multiple web applications. There are a some use cases however where having multiple indexes or multiple cores through Solr itself may make sense. Multiple cores: Deployment issues within some organizations where IT will resist deploying multiple web applications. Seamless schema update where you can create a new core and switch to it without starting/stopping servers. Embedding Solr in your own application (instead of 'raw' Lucene) and functionally need to segregate schemas collections. Multiple indexes: Multiple language collections where each document exists in different languages, analysis being language dependant. Having document types that have nothing (or very little) in common with respect to their schema, their lifetime/update frequencies or even collection sizes. HOW: The best analogy is to consider that instead of deploying multiple web-application, you can have one web-application that hosts more than one Solr core. The patch does not change any of the core logic (nor the core code); each core is configured behaves exactly as the one core in 1.2; the various caches are per-core so is the info-bean-registry. What the patch does is replace the SolrCore singleton by a collection of cores; all the code modifications are driven by the removal of the different singletons (the config, the schema the core). Each core is 'named' and a static map (keyed by name) allows to easily manage them. You declare one servlet filter mapping per core you want to expose in the web.xml; this allows easy to access each core through a different url. USAGE (example web deployment, patch installed): Step0 java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml monitor.ml Will index the 2 documents in solr.xml monitor.xml Step1: http://localhost:8983/solr/core0/admin/stats.jsp Will produce the statistics page from the admin servlet on core0 index; 2 documents Step2: http://localhost:8983/solr/core1/admin/stats.jsp Will produce the statistics page from the admin servlet on core1 index; no documents Step3: java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1; running queries from the admin interface, you can verify indexes have different content. USAGE (Java code): //create a configuration SolrConfig config = new SolrConfig(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); PATCH MODIFICATIONS DETAILS (per package): org.apache.solr.core: The heaviest modifications are in SolrCore SolrConfig. SolrCore is the most obvious modification; instead of a singleton, there is a static map of cores keyed by names and assorted methods. To retain some compatibility, the 'null' named core replaces the singleton for the relevant methods, for instance SolrCore.getCore(). One small constraint on the core name is they can't contain '/' or '\' avoiding potential url file path problems.
Re: Master/Slave and Primary/Secondary
As it pertains to Solr, I've often used Master and Searcher. Probably even more correct would be Indexer and Searcher. Primary and Secondary don't quite sound right for the Solr situation... (but Master and Slave doesn't capture it any better either). -Yonik On 7/26/07, Sundling, Paul [EMAIL PROTECTED] wrote: When I started computing it was always Master and Slave. In the last several years I've seen people use Primary and Secondary instead. When I saw the old style I looked it up and this is what I found: http://en.wikipedia.org/wiki/Master-slave_%28computers%29 http://www.techspot.com/news/9129-master-and-slave-computer-labels-unacc eptable.html http://www.smh.com.au/articles/2003/11/26/1069825847240.html Is it was worth changing the terminology from master/slave to primary/secondary? My personal feeling is that the original impetus behind some of the change was ridiculous, but it's a simple change to make. Consider this a thought bubble, not a request. Paul Sundling
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515912 ] Ryan McKinley commented on SOLR-215: 1. Re TokenizerFactory - what will break with this change? Personally, I don't have any problem with it. But is is an API breaking change (a custom 1.2 TokenizerFactory would not work with 1.3). I am fine with noting that in CHANGES.txt, but we should make sure more people are aware of this change. 2. So can SolrUpdateServlet get axed, so SolrInit can be eliminated? lets not axe SolrUpdateServlet just yet -- this patch does not need to touch SolrUpdateServlet and SolrInit can be removed. If we can resolve these two, it sounds like we can commit this patch and then work on the rest. +1 For now, I think we should remove anything in this patch that touches o.a.s.webapp.* and o.a.s.handler.* With Multiple Solr Cores working, we can bat around the best interface to accessing/modifying them. Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-215.patch, solr-215.patch, solr-215.patch, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip, solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch, solr-trunk-542847.patch, solr-trunk-src.patch WHAT: As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index. This patch is intended to allow multiple cores in Solr which also brings multiple indexes capability. The patch file to grab is solr-215.patch.zip (see MISC session below). WHY: The current Solr practical wisdom is that one schema - thus one index - is most likely to accomodate your indexing needs, using a filter to segregate documents if needed. If you really need multiple indexes, deploy multiple web applications. There are a some use cases however where having multiple indexes or multiple cores through Solr itself may make sense. Multiple cores: Deployment issues within some organizations where IT will resist deploying multiple web applications. Seamless schema update where you can create a new core and switch to it without starting/stopping servers. Embedding Solr in your own application (instead of 'raw' Lucene) and functionally need to segregate schemas collections. Multiple indexes: Multiple language collections where each document exists in different languages, analysis being language dependant. Having document types that have nothing (or very little) in common with respect to their schema, their lifetime/update frequencies or even collection sizes. HOW: The best analogy is to consider that instead of deploying multiple web-application, you can have one web-application that hosts more than one Solr core. The patch does not change any of the core logic (nor the core code); each core is configured behaves exactly as the one core in 1.2; the various caches are per-core so is the info-bean-registry. What the patch does is replace the SolrCore singleton by a collection of cores; all the code modifications are driven by the removal of the different singletons (the config, the schema the core). Each core is 'named' and a static map (keyed by name) allows to easily manage them. You declare one servlet filter mapping per core you want to expose in the web.xml; this allows easy to access each core through a different url. USAGE (example web deployment, patch installed): Step0 java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml monitor.ml Will index the 2 documents in solr.xml monitor.xml Step1: http://localhost:8983/solr/core0/admin/stats.jsp Will produce the statistics page from the admin servlet on core0 index; 2 documents Step2: http://localhost:8983/solr/core1/admin/stats.jsp Will produce the statistics page from the admin servlet on core1 index; no documents Step3: java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1; running queries from the admin interface, you can verify indexes have different content. USAGE (Java code): //create a configuration SolrConfig config = new SolrConfig(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); PATCH MODIFICATIONS DETAILS (per package): org.apache.solr.core: The
Re: FW: EdgeNGramTokenizer errors in eclipse
On 7/26/07, Sundling, Paul [EMAIL PROTECTED] wrote: Has anyone else noticed this? I didn't get any response on the user list. Yes, I have the same problem. The ant build works. I just deleted that file, and it compile fine. That may cause problems when I try to enable spell checking next week, though. Tom Paul Sundling -Original Message- From: Sundling, Paul Sent: Tuesday, July 24, 2007 4:55 PM To: [EMAIL PROTECTED] Subject: EdgeNGramTokenizer errors in eclipse I checked out the latest solr source code from subversion and put it in an eclipse project. I used all the jars for the project (had to add junit). I get errors in eclipse about two constants not being defined in one of the library jars: (based on imports org.apache.lucene.analysis.ngram.EdgeNGramTokenizer) EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE and EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE are not defined. So was a class changed that this Solr class depends on? The error happens in org.apache.solr.analysis.EdgeNGramTokenizerFactory: maxGramSize = (maxArg != null ? Integer.parseInt(maxArg) : EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE); String minArg = args.get(minGramSize); minGramSize = (minArg != null ? Integer.parseInt(minArg) : EdgeNGramTokenizer.DEFAULT_MIN_GRAM_SIZE); Am I doing something wrong? Paul Sundling
[jira] Commented: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515799 ] Stu Hood commented on SOLR-320: --- Thanks Mike! DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Assignee: Mike Klaas Fix For: 1.3 Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515784 ] Mike Klaas commented on SOLR-320: - Thanks for the bug report! I should be able to fix this momentarily. DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515746 ] Stu Hood commented on SOLR-320: --- Additionally, with the attached files, I noticed that disabling autoCommit fixes the problem. DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood updated SOLR-320: -- Attachment: solr-runner.tgz Here is a little embedded Solr testcase that exhibits the problem. See the README file for instructions. DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-320) DirectUpdateHandler2 threading issue
DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
FW: EdgeNGramTokenizer errors in eclipse
Has anyone else noticed this? I didn't get any response on the user list. Paul Sundling -Original Message- From: Sundling, Paul Sent: Tuesday, July 24, 2007 4:55 PM To: [EMAIL PROTECTED] Subject: EdgeNGramTokenizer errors in eclipse I checked out the latest solr source code from subversion and put it in an eclipse project. I used all the jars for the project (had to add junit). I get errors in eclipse about two constants not being defined in one of the library jars: (based on imports org.apache.lucene.analysis.ngram.EdgeNGramTokenizer) EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE and EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE are not defined. So was a class changed that this Solr class depends on? The error happens in org.apache.solr.analysis.EdgeNGramTokenizerFactory: maxGramSize = (maxArg != null ? Integer.parseInt(maxArg) : EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE); String minArg = args.get(minGramSize); minGramSize = (minArg != null ? Integer.parseInt(minArg) : EdgeNGramTokenizer.DEFAULT_MIN_GRAM_SIZE); Am I doing something wrong? Paul Sundling
[jira] Resolved: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-320. - Resolution: Fixed Fix Version/s: 1.3 Assignee: Mike Klaas Fixed in r559887 DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Assignee: Mike Klaas Fix For: 1.3 Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FW: EdgeNGramTokenizer errors in eclipse
I'll have a look at this later today or tomorrow (don't have source code + project handy at the moment), but somebody else might get to it before me. Otis - Original Message From: Tom Hill [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Friday, July 27, 2007 12:43:09 AM Subject: Re: FW: EdgeNGramTokenizer errors in eclipse On 7/26/07, Sundling, Paul [EMAIL PROTECTED] wrote: Has anyone else noticed this? I didn't get any response on the user list. Yes, I have the same problem. The ant build works. I just deleted that file, and it compile fine. That may cause problems when I try to enable spell checking next week, though. Tom Paul Sundling -Original Message- From: Sundling, Paul Sent: Tuesday, July 24, 2007 4:55 PM To: [EMAIL PROTECTED] Subject: EdgeNGramTokenizer errors in eclipse I checked out the latest solr source code from subversion and put it in an eclipse project. I used all the jars for the project (had to add junit). I get errors in eclipse about two constants not being defined in one of the library jars: (based on imports org.apache.lucene.analysis.ngram.EdgeNGramTokenizer) EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE and EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE are not defined. So was a class changed that this Solr class depends on? The error happens in org.apache.solr.analysis.EdgeNGramTokenizerFactory: maxGramSize = (maxArg != null ? Integer.parseInt(maxArg) : EdgeNGramTokenizer.DEFAULT_MAX_GRAM_SIZE); String minArg = args.get(minGramSize); minGramSize = (minArg != null ? Integer.parseInt(minArg) : EdgeNGramTokenizer.DEFAULT_MIN_GRAM_SIZE); Am I doing something wrong? Paul Sundling
[jira] Commented: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515788 ] Mike Klaas commented on SOLR-320: - This fixes the problem for me: Index: src/java/org/apache/solr/update/DirectUpdateHandler2.java === --- src/java/org/apache/solr/update/DirectUpdateHandler2.java (revision 559884) +++ src/java/org/apache/solr/update/DirectUpdateHandler2.java (working copy) @@ -566,6 +566,7 @@ tracker.pending.cancel( true ); tracker.pending = null; } + tracker.scheduler.shutdown(); doDeletions(); closeSearcher(); closeWriter(); DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Fix For: 1.3 Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-320) DirectUpdateHandler2 threading issue
[ https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515809 ] J.J. Larrea commented on SOLR-320: -- This was biting me too... thanks for filing the detailed report + testcase, Stu, and the super-quick fix, Mike! DirectUpdateHandler2 threading issue Key: SOLR-320 URL: https://issues.apache.org/jira/browse/SOLR-320 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: Ubuntu 7.04, Java 1.6.0-b105 Reporter: Stu Hood Assignee: Mike Klaas Fix For: 1.3 Attachments: solr-runner.tgz While working on an embedded Solr solution, I noticed that one of the threads created during typical usage of (SolrCore, DocumentBuilder and UpdateHandler), was not dying. I wrote a small embedded Solr app, and running it under JDB made it clear that the environment was not finishing cleanly because of a thread called pool-2-thread-1 in cond. waiting state. After a quick grep, I saw that only one class uses a thread pool, and that is the DirectUpdateHandler2. It uses an instance of ScheduledExecutorService to manage autocommit threads, but it apparently isn't dieing correctly. I'll start working on a patch, but the original author of the handler probably has more knowledge (see https://issues.apache.org/jira/browse/SOLR-65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
