[jira] Updated: (SOLR-729) Context.getDataSource(String) gives wrong DataSource instance
[
https://issues.apache.org/jira/browse/SOLR-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-729:
---
Attachment: SOLR-729.patch
Updated patch with a test case which reproduces the bug and verifies the fix.
I plan to commit this shortly.
> Context.getDataSource(String) gives wrong DataSource instance
> -
>
> Key: SOLR-729
> URL: https://issues.apache.org/jira/browse/SOLR-729
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-729.patch, SOLR-729.patch, SOLR-729.patch
>
>
> The default implementation of Context -- ContextImpl#getDataSource(String)
> method does not use the String argument and returns the current entity's data
> source. The javadoc for this method in Context is also inconsistent.
> {code}
> /**
>* Gets a new DataSource instance with a name.
>*
>* @param name Name of the dataSource as defined in the dataSource tag
>* @return a new DataSource instance as configured for the named entity
>* @see org.apache.solr.handler.dataimport.DataSource
>*/
> public abstract DataSource getDataSource(String name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Description: These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index * *register*: registers all aliases of a SolrCore h4. SolrCore alias operations * *swap*: swaps 2 aliases ** method: swap * *alias*: creates 1 alias for a core, potentially unaliasing a previously used alias ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *unalias*: removes 1 alias for a core ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *rename*: renames a core h3. CoreAdminHandler: handles CoreContainer operations * *load*/*create*: CoreContainer load * *unload*: CoreContainer unload * *reload*: CoreContainer reload * *swap*: CoreContainer swap * *alias*: CoreContainer alias * *unalias*: CoreContainer unalias * *rename*: CoreContainer rename * *persist*: CoreContainer persist, writes the solr.xml **stauts*: returns the status of all/one SolrCore was: These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-common: [mkdir] Created dir: /tmp/apache-solr-nightly/build/common [javac] Compiling 36 source files to /tmp/apache-solr-nightly/build/common [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/common/util/FastInputStream.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 338 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 26 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. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj: [javac] Compiling 2 source files to /tmp/apache-solr-nightly/build/client/solrj compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 113 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: 19, Failures: 0, Errors: 0, Time elapsed: 25.409 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.728 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.496 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.768 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.11 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.13 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.912 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 28.961 sec [junit] 2008-08-28 08:09:13.910::INFO: Shutdown hook executing [junit] 2008-08-28 08:09:13.910::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:14.917::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:15.926::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:16.936::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:17.946::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:18.956::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:19.965::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:20.975::INFO: Shutdown hook complete [junit] 2008-08-28 08:09:21.985::INFO: Shutdown hook complete [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.148 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.907 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.026 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.081 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.052 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.025 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.998 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures:
[jira] Created: (SOLR-734) NPE in SolrCore
NPE in SolrCore --- Key: SOLR-734 URL: https://issues.apache.org/jira/browse/SOLR-734 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Nikhil Chhaochharia Fix For: 1.3 SolrCore.getStatistics() calls getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Index two different data
Hi I want to index two different files in solr.(for ex) I want to store two tables like, job_post and job_profile in solr. But now both are stored in same place in solr.when i get data from job_post, data come from job_profile also.So i want to maintain the data of job_post and job_profile separately. thanks in advance suggest me a good solutions with Regards, Santhanaraj R
Re: Index two different data
Please use the solr-user mailing list for questions related to usage. It has a wider audience and you will get more help. On Thu, Aug 28, 2008 at 3:10 PM, santhana raj <[EMAIL PROTECTED]> wrote: > Hi > I want to index two different files in solr.(for ex) I want to store > two tables like, job_post and job_profile in solr. But now both are stored > in same place in solr.when i get data from job_post, data come from > job_profile also.So i want to maintain the data of job_post and job_profile > separately. > thanks in advance > suggest me a good solutions > > with Regards, > Santhanaraj R > -- Regards, Shalin Shekhar Mangar.
[jira] Commented: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626520#action_12626520 ] Henri Biestro commented on SOLR-734: It should not be possible to build a SolrCore with a null CoreDescriptor (the ctor that explicitly passes a null should never be called). Could you give a bit more of information on your case? > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626522#action_12626522 ] henrib edited comment on SOLR-725 at 8/28/08 4:30 AM: - added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; minor modifications so calling close is usually performed outside of the synchronized block on cores (to reduce contention). change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. was (Author: henrib): added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-735) CoreContainer.unload should remove all aliases of a core
CoreContainer.unload should remove all aliases of a core Key: SOLR-735 URL: https://issues.apache.org/jira/browse/SOLR-735 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro Similar to SOLR-722, this is a *core* operation (like load/reload); it should affect all aliases of a core. In this case, it should close the core through all its aliases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626530#action_12626530 ] Noble Paul commented on SOLR-725: - bq.It's like a rename, but doesn't remove the source. Is RENAME really used ? is it useful? bq.That's not atomic... requests that come in between can fail. Point taken . bq.you already can have these problems with swap SWAP is a special case . It always ensure that the original name is not gone. The url will remain valid . SWAP is very useful if you wish to test the core before replacing it with an existing core. Because Solr is mostly used as a web-app , I feel the url is an important identifier for an asset (till it is removed). It is OK to make it available by another name (I can always have a fixed url with the name , other names can come and go ). But, the asset remaining alive and the url is invalid makes me think of it as a not so desirable feature. bq.I dont see how aliases are different than the name itself; My proposal wanted to treat them as different. Name is fixed , and aliases are like symlinks. And the core does not even have to be aware of it. I am just -0 on the hardlink approach. I just made my points against it > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626537#action_12626537 ] Nikhil Chhaochharia commented on SOLR-734: -- I have a SolrConfig object and an IndexSchema object. I was using them to create an instance of SolrCore. Passing null as CoreDescriptor was working atleast till the 14th-Aug nightly. I want to get an instance of SolrCore and am slightly confused with the CoreDescriptor, CoreContainer etc. that have been recently introduced. The best thing for me would be a code snippet which shows how to create a SolrCore if I have a SolrConfig object and an IndexSchema object. BTW, I had posted this issue on the mailing list also and it is being discussed there also. > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626540#action_12626540 ] Henri Biestro commented on SOLR-734: Seen the thread as http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-to19197004.html Hava a look at the org.apache.solr.util.TestHarness initializer , that should be close to it. > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Branch 1.3 created
On Thu, Aug 28, 2008 at 3:51 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > OK, so I think we're officially in code freeze. It's probably easiest > to re-make the branch. > We probably shouldn't check in anything to trunk that shouldn't be > checked into the branch though. > So should I check in code only to trunk or in both the places? I plan to commit a few DataImportHandler bugs. -- Regards, Shalin Shekhar Mangar.
Naming: CoreContainer and "core" term
Hi, CoreContainer is new, so maybe I'm just not yet intimately familiar with it, but I wonder if newcomers to Solr will be confused by the name "CoreContainer" which sounds rather "singular", when in fact it seems to hold references to all SolrCores. Maybe native English speakers will automatically think "Ah, it's a container and a container is used for containing multiple things", but at least my non-native English brain is still in a process of accepting that "CoreContainer" holds multiple cores, not just one. Would simply "Cores" be better? Also, and it may be too late for this one, the name "core" might be a bad choice, at least now that we have multi-core CPUs. The other day I was talking to somebody about Solr, about hardware choices. I then mentioned Solr MultiCore and confused the person. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
[jira] Created: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
Key: SOLR-736
URL: https://issues.apache.org/jira/browse/SOLR-736
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
final SolrConfig solrConfig = new SolrConfig();
final IndexSchema indexSchema = new IndexSchema(solrConfig,
"schema.xml", null);
CoreContainer.Initializer init = new CoreContainer.Initializer() {
@Override
public CoreContainer initialize() {
CoreContainer container = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
CoreDescriptor dcore = new CoreDescriptor("",
solrConfig.getResourceLoader().getInstanceDir());
dcore.setCoreContainer(container);
dcore.setConfigName(solrConfig.getResourceName());
dcore.setSchemaName(indexSchema.getResourceName());
SolrCore core = new SolrCore(null, null, solrConfig, indexSchema,
dcore);
container.register(null, core, false);
return container;
}
};
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626572#action_12626572
]
Shalin Shekhar Mangar commented on SOLR-617:
Thanks for the patch Akshay!
I think we should allow a user to specify his custom IndexDeletionPolicy too.
We can provide a default implementation with all the options specified in the
issue description. So I propose that we have the following syntax:
{code:xml}
{code}
The default implementation will be SolrIndexDeletionPolicy which can be
configured through a NamedList. Any custom deletion policy will be initialized
with a NamedList if it implements NamedListInitializedPlugin.
{code:xml}
true
{code}
To facilitate replication, we can have a wrapper over the IndexDeletionPolicy
which can provide us the features needed for replication (SOLR-561). We need
access to a list of non-deleted IndexCommit instances, a way to lookup
IndexCommit given a version as well as the latest commit point.
> Allow configurable deletion policy
> --
>
> Key: SOLR-617
> URL: https://issues.apache.org/jira/browse/SOLR-617
> Project: Solr
> Issue Type: New Feature
> Components: search, update
>Affects Versions: 1.4
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solr-617.patch
>
>
> Lucene API provides means to configure deletion policy. Solr should be able
> to expose it through configuration in solrconfig.xml. Moreover the new
> replication (SOLR-561) strategy is going to rely on this .
> I propose the configuration go into the section
> sample configuration
> {code:xml|title=solrconfig.xml}
>
>
>
>
> true
>
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
[
https://issues.apache.org/jira/browse/SOLR-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-736:
---
Description:
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
CoreContainer.Initializer init = new CoreContainer.Initializer();
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
was:
The method is deprecated but one can still initialize & start working this way.
Potential fix could be:
{code}
@Deprecated
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
if( instance == null ) {
try {
// sets 'instance' to the latest solr core
final SolrConfig solrConfig = new SolrConfig();
final IndexSchema indexSchema = new IndexSchema(solrConfig,
"schema.xml", null);
CoreContainer.Initializer init = new CoreContainer.Initializer() {
@Override
public CoreContainer initialize() {
CoreContainer container = new CoreContainer(new
SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
CoreDescriptor dcore = new CoreDescriptor("",
solrConfig.getResourceLoader().getInstanceDir());
dcore.setCoreContainer(container);
dcore.setConfigName(solrConfig.getResourceName());
dcore.setSchemaName(indexSchema.getResourceName());
SolrCore core = new SolrCore(null, null, solrConfig, indexSchema,
dcore);
container.register(null, core, false);
return container;
}
};
instance = init.initialize().getCore("");
} catch(Exception xany) {
throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
"error creating core", xany );
}
}
}
return instance;
}
{code}
> SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
>
>
> Key: SOLR-736
> URL: https://issues.apache.org/jira/browse/SOLR-736
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>
> The method is deprecated but one can still initialize & start working this
> way.
> Potential fix could be:
> {code}
> @Deprecated
> public static SolrCore getSolrCore() {
> synchronized( SolrCore.class ) {
> if( instance == null ) {
> try {
> // sets 'instance' to the latest solr core
> CoreContainer.Initializer init = new CoreContainer.Initializer();
> instance = init.initialize().getCore("");
> } catch(Exception xany) {
> throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
> "error creating core", xany );
> }
> }
> }
> return instance;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Branch 1.3 created
Both. On Aug 28, 2008, at 9:47 AM, Shalin Shekhar Mangar wrote: On Thu, Aug 28, 2008 at 3:51 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote: OK, so I think we're officially in code freeze. It's probably easiest to re-make the branch. We probably shouldn't check in anything to trunk that shouldn't be checked into the branch though. So should I check in code only to trunk or in both the places? I plan to commit a few DataImportHandler bugs. -- Regards, Shalin Shekhar Mangar.
Re: Branch 1.3 created
I imagine the change should be made on one and merged to the other, right? On Thu, Aug 28, 2008 at 10:21 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > Both. > > > On Aug 28, 2008, at 9:47 AM, Shalin Shekhar Mangar wrote: > >> On Thu, Aug 28, 2008 at 3:51 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote: >> >>> OK, so I think we're officially in code freeze. It's probably easiest >>> to re-make the branch. >>> We probably shouldn't check in anything to trunk that shouldn't be >>> checked into the branch though. >>> >> >> So should I check in code only to trunk or in both the places? I plan to >> commit a few DataImportHandler bugs. >> >> -- >> Regards, >> Shalin Shekhar Mangar. > >
[jira] Created: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
Incorrect 500 error reported with maxClausCount limit - Key: SOLR-737 URL: https://issues.apache.org/jira/browse/SOLR-737 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Andrew Nagy Fix For: 1.3 Here is my installation: Solr Specification Version: 1.2.2008.08.13.13.05.16 Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 I did the following query today: author:(r*a* AND fisher) And get the following 500 error: maxClauseCount is set to 1024 org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set to 1024 at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) at org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) at org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) at org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) at org.apache.lucene.search.Query.weight(Query.java:94) at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) at org.apache.lucene.search.Searcher.search(Searcher.java:126) at org.apache.lucene.search.Searcher.search(Searcher.java:105) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-737: -- Priority: Minor (was: Major) Fix Version/s: (was: 1.3) 1.4 Issue Type: Improvement (was: Bug) > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626611#action_12626611 ] Andrew Nagy commented on SOLR-737: -- Why has this been relegated to an improvement and held to 1.4? This is a major showstopper bug for me - unless I am understanding something incorrectly? > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626615#action_12626615 ] Mark Miller commented on SOLR-737: -- Because its an artificial limitation from lucene - truncation queries expand to one clause per possible term in the index - generate enough of these clauses and you have a *really* slow search. Lucene bails at the default of 1024. Not sure if this setting is available in solr, but as Otis marked as improvement, I would guess not and the idea is to add it. Its not a bug though - your wildcard term is just matching over 1024 terms in the index. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626619#action_12626619 ] Andrew Nagy commented on SOLR-737: -- Thanks Mark for clarification. This makes sense now. Solr does already have a configurable maxClauseCount and the default is 1024. Can anyone supply more information on whether or not this is something that can be enhanced in Lucene - for me this is a very important query and since I have well over a million documents - I will never be able to issue this query. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626621#action_12626621 ] Andrew Nagy commented on SOLR-737: -- Sorry to keep blathering on - but I am trying to understand this issue better. If I issue the query (r* AND fisher) the results come back to me immediately ... no slow down what so ever. And an r* is going to have many many more possibilities than r*a* - it still seems like there is a bug here. Can anyone clarify how lucene handles this? > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626620#action_12626620 ] Erik Hatcher commented on SOLR-737: --- Andrew - for one, you can increase the boolean clause limit (at the risk of a less performant query). In solrconfig, adjust this: 1024 Also, there are many tricks that can be played to make wildcard querying more efficient if you are willing to sacrifice index size and manage index analyzer and query analyzer carefully. Have a look this topic in the [EMAIL PROTECTED] archives. I did a lot of work once upon a time for a client that involved term rotation during indexing and then morphing wildcard queries to have maximal prefix for best efficiency. As a thought experiment - consider what you'd do if you had to satisfy a patrons request for "find me all books matching r*a* in the title" using a card catalog system! :) > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this em
[jira] Issue Comment Edited: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626628#action_12626628 ] [EMAIL PROTECTED] edited comment on SOLR-737 at 8/28/08 8:40 AM: r* is a prefix query that Solr turns into a ConstantScorePrefixQuery r*a* is a wildcard query it should eventually get the same treatment, but we don't currently have a ConstantScoreWildcardQuery. was (Author: [EMAIL PROTECTED]): r* is a prefix query that Solr turns into a ConstantScorePrefixQuery r*a* is a wildcard query it should eventually get the same treatment. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626628#action_12626628 ] Yonik Seeley commented on SOLR-737: --- r* is a prefix query that Solr turns into a ConstantScorePrefixQuery r*a* is a wildcard query it should eventually get the same treatment. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-729) Context.getDataSource(String) gives wrong DataSource instance
[
https://issues.apache.org/jira/browse/SOLR-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-729.
Resolution: Fixed
Committed revision 689867.
Thanks Noble!
> Context.getDataSource(String) gives wrong DataSource instance
> -
>
> Key: SOLR-729
> URL: https://issues.apache.org/jira/browse/SOLR-729
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.3
>
> Attachments: SOLR-729.patch, SOLR-729.patch, SOLR-729.patch
>
>
> The default implementation of Context -- ContextImpl#getDataSource(String)
> method does not use the String argument and returns the current entity's data
> source. The javadoc for this method in Context is also inconsistent.
> {code}
> /**
>* Gets a new DataSource instance with a name.
>*
>* @param name Name of the dataSource as defined in the dataSource tag
>* @return a new DataSource instance as configured for the named entity
>* @see org.apache.solr.handler.dataimport.DataSource
>*/
> public abstract DataSource getDataSource(String name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-737: -- Attachment: SOLR-737.patch Here's a quick patch to fix things. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-737.patch > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-726) driver and datasources are not loaded using the multicore lib aware SolrResourceLoader
[
https://issues.apache.org/jira/browse/SOLR-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626645#action_12626645
]
Shalin Shekhar Mangar commented on SOLR-726:
Using SolrResourceLoader#findClass does not solve the problem. From the
official documentation at
http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/drivermanager.html
{quote}
For security reasons, the JDBC management layer will keep track of which class
loader provided which driver. Then when the DriverManager class is opening a
connection, it will use only drivers that come from the local file system or
from the same class loader as the code issuing the request for a connection.
{quote}
Since the loading is done by SolrResourceLoader using a different class loader
and the call to DriverManager.getConnection is made from a different one, a
SQLException is thrown -- "java.sql.SQLException: No suitable driver".
> driver and datasources are not loaded using the multicore lib aware
> SolrResourceLoader
> --
>
> Key: SOLR-726
> URL: https://issues.apache.org/jira/browse/SOLR-726
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Walter Ferrara
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-726.patch
>
>
> see
> http://www.nabble.com/dataimporthandler-and-mysql-connector-jar-td19146229.html
> The jar containing the (jdbc) driver have to be present in the java
> classpath. Putting it in coreX/lib or in the shared lib dir of a multicore
> solr doesn't work
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626648#action_12626648 ] Yonik Seeley commented on SOLR-737: --- Thinking on this a little further, I do think this is a bug, and I do think it warrants going into 1.3 The original range and prefix queries were broken, and I fixed them via ConstantScoreQuery. I never did it for wildcard query because the company I worked for at the time didn't use them. But any query that explodes when you change the index is arguably broken. Objections to this going into 1.3? > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-737.patch > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626653#action_12626653 ] Shalin Shekhar Mangar commented on SOLR-737: +1 for marking for 1.3 Does it also make execution of these queries any faster? Sorry, I'm not very familiar with ConstantScoreQuery and related Lucene classes. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-737.patch > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626655#action_12626655 ] Yonik Seeley commented on SOLR-737: --- bq. Does it also make execution of these queries any faster? On balance, I think so. If only a few terms would be matched, it will be a little slower. If a lot of terms are matched, then it will normally be faster. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-737.patch > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-733) Refactor or expose methods processDelete(), processUpdate(), readDoc() in XmlUpdateRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626658#action_12626658 ] aaronwhittier edited comment on SOLR-733 at 8/28/08 10:26 AM: --- I don't think the UpdateRequestProcessor will let me do what I want. Let me describe what we're trying to do - maybe I can do it easily without cloning XmlUpdateRequestHandler. We want to add additional data to the XML tag, a tag which has a couple attributes, and whose contents are textual data. We want to translate this data into different text and then attach it to one of the lucene fields in the SolrInputDocument, which can then be processed normally. What I want, I think, is to be able to override the readDoc() method in XmlUpdateRequestHandler. Does that make sense? I could easily be missing a simple solution, as I'm new to Solr. was (Author: aaronwhittier): I don't think the UpdateRequestProcessor will let me do what I want. Let me describe what we're trying to do - maybe I can do it easily without cloning XmlUpdateRequestHandler. We want to add additional data to the XML tag, a tag which has a couple attributes, and whose contents are textual data. We want to translate this data into text and then attach it to one of the lucene fields in the SolrInputDocument, which can then be processed normally. What I want, I think, is to be able to override the readDoc() method in XmlUpdateRequestHandler. Does that make sense? I could easily be missing a simple solution, as I'm new to Solr. > Refactor or expose methods processDelete(), processUpdate(), readDoc() in > XmlUpdateRequestHandler > -- > > Key: SOLR-733 > URL: https://issues.apache.org/jira/browse/SOLR-733 > Project: Solr > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Aaron Whittier >Priority: Minor > > We are extending the functionality of XmlUpdateRequestHandler in our > application with a couple simple changes, but because the processDelete(), > processUpdate(), readDoc() are package-private, we've had to copy most of > XmlUpdateRequestHandler, whether we changed any parts or not. Can those be > made more pluggable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-733) Refactor or expose methods processDelete(), processUpdate(), readDoc() in XmlUpdateRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626658#action_12626658 ] Aaron Whittier commented on SOLR-733: - I don't think the UpdateRequestProcessor will let me do what I want. Let me describe what we're trying to do - maybe I can do it easily without cloning XmlUpdateRequestHandler. We want to add additional data to the XML tag, a tag which has a couple attributes, and whose contents are textual data. We want to translate this data into text and then attach it to one of the lucene fields in the SolrInputDocument, which can then be processed normally. What I want, I think, is to be able to override the readDoc() method in XmlUpdateRequestHandler. Does that make sense? I could easily be missing a simple solution, as I'm new to Solr. > Refactor or expose methods processDelete(), processUpdate(), readDoc() in > XmlUpdateRequestHandler > -- > > Key: SOLR-733 > URL: https://issues.apache.org/jira/browse/SOLR-733 > Project: Solr > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Aaron Whittier >Priority: Minor > > We are extending the functionality of XmlUpdateRequestHandler in our > application with a couple simple changes, but because the processDelete(), > processUpdate(), readDoc() are package-private, we've had to copy most of > XmlUpdateRequestHandler, whether we changed any parts or not. Can those be > made more pluggable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-733) Refactor or expose methods processDelete(), processUpdate(), readDoc() in XmlUpdateRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626668#action_12626668 ] Shalin Shekhar Mangar commented on SOLR-733: I think that is possible with UpdateRequestProcessor. Instead of adding a custom tag to the XML, add them as normal fields (metadata1, 2, ...) which will be added to SolrInputDocument. In the processAdd method you will get access to the value by using SolrInputDocument#getValue(String field). Use them in whatever way you want, remove them from SolrInputDocument and add the final processed text to a new field using SolrInputDocument#addField and finally pass on for indexing by calling super.processAdd(SolrInputDocument). > Refactor or expose methods processDelete(), processUpdate(), readDoc() in > XmlUpdateRequestHandler > -- > > Key: SOLR-733 > URL: https://issues.apache.org/jira/browse/SOLR-733 > Project: Solr > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Aaron Whittier >Priority: Minor > > We are extending the functionality of XmlUpdateRequestHandler in our > application with a couple simple changes, but because the processDelete(), > processUpdate(), readDoc() are package-private, we've had to copy most of > XmlUpdateRequestHandler, whether we changed any parts or not. Can those be > made more pluggable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-734) NPE in SolrCore
So, is this a bug or not? It sounds like it was resolved, right? On Aug 28, 2008, at 8:31 AM, Henri Biestro (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626540 #action_12626540 ] Henri Biestro commented on SOLR-734: Seen the thread as http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-to19197004.html Hava a look at the org.apache.solr.util.TestHarness initializer , that should be close to it. NPE in SolrCore --- Key: SOLR-734 URL: https://issues.apache.org/jira/browse/SOLR-734 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Nikhil Chhaochharia Fix For: 1.3 SolrCore.getStatistics() calls getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Package Access Issues / Extending FacetComponent
Thanks, I'll do that. I'll wait until 1.3 has been released to submit a patch. (This will be my first one, so bear with me!) hossman wrote: > > > : 1. Copy all those classes into my own package, copy the FacetComponent > into > : my own package, and then override as I intended (there might still be > some > : issues with accessing ResponseBuilder._facetInfo). > : 2. Re-write the entire component using only the ShardResponse. > : 3. Make those classes publicly accessible. > > short term 1&2 are your best bets ... long term submit a patch that > makes things public/protected as you think are warranted. We'll use the > Jira issue to discuss wether those are APIs that we want to really expose > to plugin developers, or if we want to refactor the APIs to clean them up. > > (many things tend to be private or package-protected initally to protect > against people using half baked APIs ... it's discussions like this theat > help shake them out and make them more robust and usable) > > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-tp19148122p19206872.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: svn commit: r689867 - in /lucene/solr/trunk/contrib/dataimporthandler: ./ src/main/java/org/apache/solr/handler/dataimport/ src/test/java/org/apache/solr/handler/dataimport/ src/test/resources/sol
SOLR-729 is marked as fixed in 1.3, but i don't see this commited to the
1.3 branch?
: Date: Thu, 28 Aug 2008 16:04:46 -
: From: [EMAIL PROTECTED]
: Reply-To: solr-dev@lucene.apache.org
: To: [EMAIL PROTECTED]
: Subject: svn commit: r689867 - in
: /lucene/solr/trunk/contrib/dataimporthandler: ./
: src/main/java/org/apache/solr/handler/dataimport/
: src/test/java/org/apache/solr/handler/dataimport/
: src/test/resources/solr/conf/
:
: Author: shalin
: Date: Thu Aug 28 09:04:45 2008
: New Revision: 689867
:
: URL: http://svn.apache.org/viewvc?rev=689867&view=rev
: Log:
: SOLR-729 -- Context.getDataSource(String) gives current entity's DataSource
instance regardless of argument.
:
: Added:
:
lucene/solr/trunk/contrib/dataimporthandler/src/test/resources/solr/conf/data-config-with-transformer.xml
(with props)
: Modified:
: lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt
:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java
:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java
:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java
:
lucene/solr/trunk/contrib/dataimporthandler/src/test/java/org/apache/solr/handler/dataimport/TestDocBuilder2.java
:
: Modified: lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt
: URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt?rev=689867&r1=689866&r2=689867&view=diff
: ==
: --- lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt (original)
: +++ lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt Thu Aug 28
09:04:45 2008
: @@ -32,6 +32,9 @@
:use the complete string for parsing. Failure to do so will
result in an exception.
:(Stefan Oestreicher via shalin)
:
: +2. SOLR-729: Context.getDataSource(String) gives current entity's
DataSource instance regardless of argument.
: + (Noble Paul, shalin)
: +
: Other Changes
:
:
:
: Modified:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java
: URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java?rev=689867&r1=689866&r2=689867&view=diff
: ==
: ---
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java
(original)
: +++
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java
Thu Aug 28 09:04:45 2008
: @@ -72,18 +72,21 @@
:public abstract VariableResolver getVariableResolver();
:
:/**
: - * Gets the datasource instance defined for this entity.
: + * Gets the datasource instance defined for this entity. Do not close()
this instance.
: + * Transformers should use the getDataSource(String name) method.
: *
: * @return a new DataSource instance as configured for the current entity
: * @see org.apache.solr.handler.dataimport.DataSource
: + * @see #getDataSource(String)
: */
:public abstract DataSource getDataSource();
:
:/**
: - * Gets a new DataSource instance with a name.
: - *
: + * Gets a new DataSource instance with a name. Ensure that you close()
this after use
: + * because this is created just for this method call.
: + *
: * @param name Name of the dataSource as defined in the dataSource tag
: - * @return a new DataSource instance as configured for the named entity
: + * @return a new DataSource instance
: * @see org.apache.solr.handler.dataimport.DataSource
: */
:public abstract DataSource getDataSource(String name);
:
: Modified:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java
: URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java?rev=689867&r1=689866&r2=689867&view=diff
: ==
: ---
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java
(original)
: +++
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java
Thu Aug 28 09:04:45 2008
: @@ -63,7 +63,7 @@
:}
:
:public DataSource getDataSource(String name) {
: -return dataImporter.getDataSourceInstance(entity);
: +return dataImporter.getDataSourceInstance(entity, name, this);
:}
:
:public boolean isRootEntity() {
:
: Modified:
lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/datai
[jira] Resolved: (SOLR-733) Refactor or expose methods processDelete(), processUpdate(), readDoc() in XmlUpdateRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Whittier resolved SOLR-733. - Resolution: Fixed Ah, fantastic - that works very well. Thanks! > Refactor or expose methods processDelete(), processUpdate(), readDoc() in > XmlUpdateRequestHandler > -- > > Key: SOLR-733 > URL: https://issues.apache.org/jira/browse/SOLR-733 > Project: Solr > Issue Type: Wish >Affects Versions: 1.3 >Reporter: Aaron Whittier >Priority: Minor > > We are extending the functionality of XmlUpdateRequestHandler in our > application with a couple simple changes, but because the processDelete(), > processUpdate(), readDoc() are package-private, we've had to copy most of > XmlUpdateRequestHandler, whether we changed any parts or not. Can those be > made more pluggable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r689867 - in /lucene/solr/trunk/contrib/dataimporthandler: ./ src/main/java/org/apache/solr/handler/dataimport/ src/test/java/org/apache/solr/handler/dataimport/ src/test/resources/sol
Yeah I guess I got confused with Yonik's remark of committing to trunk and merging to the branch. I shall commit to the branch as well. On Fri, Aug 29, 2008 at 12:36 AM, Chris Hostetter <[EMAIL PROTECTED]>wrote: > > SOLR-729 is marked as fixed in 1.3, but i don't see this commited to the > 1.3 branch? > > > > : Date: Thu, 28 Aug 2008 16:04:46 - > : From: [EMAIL PROTECTED] > : Reply-To: solr-dev@lucene.apache.org > : To: [EMAIL PROTECTED] > : Subject: svn commit: r689867 - in > : /lucene/solr/trunk/contrib/dataimporthandler: ./ > : src/main/java/org/apache/solr/handler/dataimport/ > : src/test/java/org/apache/solr/handler/dataimport/ > : src/test/resources/solr/conf/ > : > : Author: shalin > : Date: Thu Aug 28 09:04:45 2008 > : New Revision: 689867 > : > : URL: http://svn.apache.org/viewvc?rev=689867&view=rev > : Log: > : SOLR-729 -- Context.getDataSource(String) gives current entity's > DataSource instance regardless of argument. > : > : Added: > : > lucene/solr/trunk/contrib/dataimporthandler/src/test/resources/solr/conf/data-config-with-transformer.xml > (with props) > : Modified: > : lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt > : > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java > : > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java > : > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java > : > lucene/solr/trunk/contrib/dataimporthandler/src/test/java/org/apache/solr/handler/dataimport/TestDocBuilder2.java > : > : Modified: lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt > : URL: > http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt?rev=689867&r1=689866&r2=689867&view=diff > : > == > : --- lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt (original) > : +++ lucene/solr/trunk/contrib/dataimporthandler/CHANGES.txt Thu Aug 28 > 09:04:45 2008 > : @@ -32,6 +32,9 @@ > :use the complete string for parsing. Failure to do so will > result in an exception. > :(Stefan Oestreicher via shalin) > : > : +2. SOLR-729: Context.getDataSource(String) gives current entity's > DataSource instance regardless of argument. > : + (Noble Paul, shalin) > : + > : Other Changes > : > : > : > : Modified: > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java > : URL: > http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java?rev=689867&r1=689866&r2=689867&view=diff > : > == > : --- > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java > (original) > : +++ > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/Context.java > Thu Aug 28 09:04:45 2008 > : @@ -72,18 +72,21 @@ > :public abstract VariableResolver getVariableResolver(); > : > :/** > : - * Gets the datasource instance defined for this entity. > : + * Gets the datasource instance defined for this entity. Do not > close() this instance. > : + * Transformers should use the getDataSource(String name) method. > : * > : * @return a new DataSource instance as configured for the current > entity > : * @see org.apache.solr.handler.dataimport.DataSource > : + * @see #getDataSource(String) > : */ > :public abstract DataSource getDataSource(); > : > :/** > : - * Gets a new DataSource instance with a name. > : - * > : + * Gets a new DataSource instance with a name. Ensure that you close() > this after use > : + * because this is created just for this method call. > : + * > : * @param name Name of the dataSource as defined in the dataSource tag > : - * @return a new DataSource instance as configured for the named > entity > : + * @return a new DataSource instance > : * @see org.apache.solr.handler.dataimport.DataSource > : */ > :public abstract DataSource getDataSource(String name); > : > : Modified: > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java > : URL: > http://svn.apache.org/viewvc/lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java?rev=689867&r1=689866&r2=689867&view=diff > : > == > : --- > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java > (original) > : +++ > lucene/solr/trunk/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/ContextImpl.java > Thu Aug 2
Re: Branch 1.3 created
On Wed, Aug 27, 2008 at 6:48 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > I will put up an RC sometime today. Since this is my first ever release, > please bear with me as I work through the details. Extra scrutiny is > appreciated. > Grant -- what is the plan for an RC? -- Regards, Shalin Shekhar Mangar.
Re: [jira] Commented: (SOLR-734) NPE in SolrCore
No, it's not a bug. Yes, the pb is solved. Grant Ingersoll-6 wrote: > > So, is this a bug or not? It sounds like it was resolved, right? > > On Aug 28, 2008, at 8:31 AM, Henri Biestro (JIRA) wrote: > >> >>[ >> https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626540 >> >> #action_12626540 ] >> >> Henri Biestro commented on SOLR-734: >> >> >> Seen the thread as >> http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-to19197004.html >> >> Hava a look at the org.apache.solr.util.TestHarness initializer , >> that should be close to it. >> >> >>> NPE in SolrCore >>> --- >>> >>>Key: SOLR-734 >>>URL: https://issues.apache.org/jira/browse/SOLR-734 >>>Project: Solr >>> Issue Type: Bug >>> Affects Versions: 1.3 >>> Reporter: Nikhil Chhaochharia >>>Fix For: 1.3 >>> >>> >>> SolrCore.getStatistics() calls >>> getCoreDescriptor().getCoreContainer().getCoreNames(this) without >>> checking if the CoreDescriptor is null. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> > > > -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28SOLR-734%29-NPE-in-SolrCore-tp19197298p19207987.html Sent from the Solr - Dev mailing list archive at Nabble.com.
update response warning
When I do an update to solr, I still get a warning it's time to remove this, right? Any other places where it should be removed? 0281 This response format is experimental. It is likely to change in the future. -Yonik
Re: Branch 1.3 created
I'm working on it, running ant clean test as we speak. On Aug 28, 2008, at 3:43 PM, Shalin Shekhar Mangar wrote: On Wed, Aug 27, 2008 at 6:48 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: I will put up an RC sometime today. Since this is my first ever release, please bear with me as I work through the details. Extra scrutiny is appreciated. Grant -- what is the plan for an RC? -- Regards, Shalin Shekhar Mangar.
Re: Branch 1.3 created
Should I wait for SOLR-728 and S-726? On Aug 28, 2008, at 3:43 PM, Shalin Shekhar Mangar wrote: On Wed, Aug 27, 2008 at 6:48 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: I will put up an RC sometime today. Since this is my first ever release, please bear with me as I work through the details. Extra scrutiny is appreciated. Grant -- what is the plan for an RC? -- Regards, Shalin Shekhar Mangar.
[jira] Resolved: (SOLR-734) NPE in SolrCore
[ https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-734. -- Resolution: Won't Fix > NPE in SolrCore > --- > > Key: SOLR-734 > URL: https://issues.apache.org/jira/browse/SOLR-734 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Nikhil Chhaochharia > Fix For: 1.3 > > > SolrCore.getStatistics() calls > getCoreDescriptor().getCoreContainer().getCoreNames(this) without checking if > the CoreDescriptor is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: update response warning
+1 We should remove those from practically everywhere for the 1.3 final, I'd think. Any response formats we're still experimenting with? Erik On Aug 28, 2008, at 4:48 PM, Yonik Seeley wrote: When I do an update to solr, I still get a warning it's time to remove this, right? Any other places where it should be removed? 0name="QTime">281 This response format is experimental. It is likely to change in the future. -Yonik
[jira] Resolved: (SOLR-737) Incorrect 500 error reported with maxClausCount limit
[ https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-737. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3 committed. I'm currently figuring out how to do a merge to commit it to the 1.3 branch also. > Incorrect 500 error reported with maxClausCount limit > - > > Key: SOLR-737 > URL: https://issues.apache.org/jira/browse/SOLR-737 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Andrew Nagy >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-737.patch > > > Here is my installation: > Solr Specification Version: 1.2.2008.08.13.13.05.16 > Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25 > I did the following query today: > author:(r*a* AND fisher) > And get the following 500 error: > maxClauseCount is set to 1024 > org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set > to 1024 > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165) > at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156) > at > org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63) > at > org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54) > at > org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385) > at > org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163) > at org.apache.lucene.search.Query.weight(Query.java:94) > at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175) > at org.apache.lucene.search.Searcher.search(Searcher.java:126) > at org.apache.lucene.search.Searcher.search(Searcher.java:105) > at > org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966) > at > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838) > at > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: update response warning
Here are the current handlers that add this warning: $ find . -name \*.java | xargs grep addExperimentalFormatWarning ./handler/admin/LukeRequestHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); ./handler/admin/PluginInfoHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); ./handler/admin/ShowFileRequestHandler.java: RequestHandlerUtils.addExperimentalFormatWarning(rsp); ./handler/admin/SystemInfoHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); ./handler/admin/ThreadDumpHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); ./handler/AnalysisRequestHandler.java: RequestHandlerUtils.addExperimentalFormatWarning(rsp); ./handler/MoreLikeThisHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); ./handler/RequestHandlerUtils.java: public static void addExperimentalFormatWarning( SolrQueryResponse rsp ) ./handler/XmlUpdateRequestHandler.java: RequestHandlerUtils.addExperimentalFormatWarning( rsp ); Which ones are actually still more in flux (or that we're not happy with and plan on changing in 1.4 perhaps)? -Yonik
solr-specific-forrest-variables.ent
Hoss, I'm doing http://wiki.apache.org/solr/Website_Update_HOWTO and I'm not getting the updates, even though I see them in build/solr-specific- forrest-variables.ent after running the ant target for it. How does Forrest pick them up from siteconf.xml? The reference in there seems to be to a local file and not the one in build/. less build/solr-specific-forrest-variables.ent But after running Forrest in the site dir, tutorial.html looks like: - This document is for Apache Solr version 1.2.2008.08.24.23.51.18. If you are using a different version of Solr, please consult the documentation that was distributed with the version you are using. + This document is for Apache Solr version 1.2.2008.08.28.14.55.52. If you are using a different version of Solr, please consult the documentation that was distributed with the version you are using. So, it's getting today's date, but not the right version. It also isn't generating tutorial.pdf which seems weird. Thanks, Grant
Re: update response warning
Spell check component should be considered experimental, I think. On Aug 28, 2008, at 4:58 PM, Erik Hatcher wrote: +1 We should remove those from practically everywhere for the 1.3 final, I'd think. Any response formats we're still experimenting with? Erik On Aug 28, 2008, at 4:48 PM, Yonik Seeley wrote: When I do an update to solr, I still get a warning it's time to remove this, right? Any other places where it should be removed? 0name="QTime">281 This response format is experimental. It is likely to change in the future. -Yonik
Re: solr-specific-forrest-variables.ent
: How does Forrest pick them up from siteconf.xml? The reference in there seems : to be to a local file and not the one in build/. catalog.xcat refers to the file using a relative path that goes all the way up and into the build dir... http://svn.apache.org/viewvc/lucene/solr/trunk/src/site/src/documentation/resources/schema/catalog.xcat : less build/solr-specific-forrest-variables.ent : : : : : But after running Forrest in the site dir, tutorial.html looks like: ... : + This document is for Apache Solr version 1.2.2008.08.28.14.55.52. If : you are using a different version of Solr, please consult the documentation : that was distributed with the version you are using. : : So, it's getting today's date, but not the right version. Even the date isn't right actually (note that the hours, minutes, and seconds are wrong) : It also isn't generating tutorial.pdf which seems weird. i think something maybe wonky about the timestamps on your files and what forrest thiks is "up to date" ... try blowing away the forrest "build" dir in src/site/src and then following the steps and see what happens (on the trunk i'm seeing it pull in solr-specific-forrest-variables.ent correctly) NOTE: when doing releases, you'll want to use "-Dversion=X.Y.M -Dspecversion=X.Y.M" on all the ant command line calls so that the spect version gets filled in with an "official" version number and not the long ugly dev version that includes the date like you're seeing here. (it's spelled out on the HowToRelease page) -Hoss
Re: svn commit: r689949 - /lucene/solr/branches/branch-1.3/CHANGES.txt
I don't think we want the "Release 1.4-dev" stuff at the top of the CHANGES.txt included in the 1.3 release. should that just added to the trunk copy? On Thu, 28 Aug 2008 [EMAIL PROTECTED] wrote: : Date: Thu, 28 Aug 2008 19:41:57 - : From: [EMAIL PROTECTED] : Reply-To: solr-dev@lucene.apache.org : To: [EMAIL PROTECTED] : Subject: svn commit: r689949 - /lucene/solr/branches/branch-1.3/CHANGES.txt : : Author: gsingers : Date: Thu Aug 28 12:41:57 2008 : New Revision: 689949 : : URL: http://svn.apache.org/viewvc?rev=689949&view=rev : Log: : update changes for release : : Modified: : lucene/solr/branches/branch-1.3/CHANGES.txt : : Modified: lucene/solr/branches/branch-1.3/CHANGES.txt : URL: http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.3/CHANGES.txt?rev=689949&r1=689948&r2=689949&view=diff : == : --- lucene/solr/branches/branch-1.3/CHANGES.txt (original) : +++ lucene/solr/branches/branch-1.3/CHANGES.txt Thu Aug 28 12:41:57 2008 : @@ -20,8 +20,34 @@ : : : $Id$ : +== Release 1.4-dev == : +Upgrading from Solr 1.3 : +--- : + : +Detailed Change List : +-- : + : +New Features : +-- : + : +Optimizations : +-- : + : +Bug Fixes : +-- : + : + : +Build : +-- : + : + : +Documentation : +-- : + : + : + : +== Release 1.3.0 20080903 == : : -== Release 1.3-dev == : : Upgrading from Solr 1.2 : --- : : -Hoss
Re: update response warning
OK, I removed all of the warnings from the handlers listed below. -Yonik On Thu, Aug 28, 2008 at 5:23 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > Here are the current handlers that add this warning: > $ find . -name \*.java | xargs grep addExperimentalFormatWarning > ./handler/admin/LukeRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/PluginInfoHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/ShowFileRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning(rsp); > ./handler/admin/SystemInfoHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/ThreadDumpHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/AnalysisRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning(rsp); > ./handler/MoreLikeThisHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/RequestHandlerUtils.java: public static void > addExperimentalFormatWarning( SolrQueryResponse rsp ) > ./handler/XmlUpdateRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > > Which ones are actually still more in flux (or that we're not happy > with and plan on changing in 1.4 perhaps)? > > -Yonik >
Re: Branch 1.3 created
On Fri, Aug 29, 2008 at 2:25 AM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > Should I wait for SOLR-728 and S-726? SOLR-726 is important, however it looks like I may need to do some research (classloader issues). If you are creating an RC within a few hours, please go ahead. If not, I'll try to fix it and you can make an RC on friday morning (your timezone). -- Regards, Shalin Shekhar Mangar.
Re: update response warning
DataImportHandler should also be considered experimental. On Fri, Aug 29, 2008 at 2:53 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > Here are the current handlers that add this warning: > $ find . -name \*.java | xargs grep addExperimentalFormatWarning > ./handler/admin/LukeRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/PluginInfoHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/ShowFileRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning(rsp); > ./handler/admin/SystemInfoHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/admin/ThreadDumpHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/AnalysisRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning(rsp); > ./handler/MoreLikeThisHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > ./handler/RequestHandlerUtils.java: public static void > addExperimentalFormatWarning( SolrQueryResponse rsp ) > ./handler/XmlUpdateRequestHandler.java: > RequestHandlerUtils.addExperimentalFormatWarning( rsp ); > > Which ones are actually still more in flux (or that we're not happy > with and plan on changing in 1.4 perhaps)? > > -Yonik > -- Regards, Shalin Shekhar Mangar.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626841#action_12626841 ] Noble Paul commented on SOLR-725: - We are building a feature as explained in SOLR-727. The idea is to make the replication admin page of master show the details of slaves as well (details like which version of the index is used by each slave etc. etc) instead of going to each slave to know that . So each slave registers itself with the master by providing the url of itself the url will be of this format http://:///replication. to make this feature work we expect the url to be fixed. If the url is a moving target it may just not work.(or it will be difficult) Another important feature is SOLR-561 itself . The configuration takes the masterUrl . The url has to be fixed for the lifetime of the solr core.If we make the url invalid this again will not work Going forward , we will have to see a Solr as a whole network of systems of multiple masters slaves and multiple shards . unlike the current strategy of seeing each instance as an island. We are making the first step in that direction . Assuming that we will be using urls to communicate with each other it is important to have a reliable/fixed url for each core. henri .I am yet to see an argument of why the symlink approach will not meet your usecases other than the point that it is not very 'elegant' . I have made my points on why the alias (in the current form and the way you propose) is going to make my usecases difficult . > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch, solr-725.patch, solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *rename*: renames a core > h3. CoreAdminHandler: handles CoreContainer operations > * *load*/*create*: CoreContainer load > * *unload*: CoreContainer unload > * *reload*: CoreContainer reload > * *swap*: CoreContainer swap > * *alias*: CoreContainer alias > * *unalias*: CoreContainer unalias > * *rename*: CoreContainer rename > * *persist*: CoreContainer persist, writes the solr.xml > **stauts*: returns the status of all/one SolrCore -- This message is automatically generate
[jira] Updated: (SOLR-726) driver and datasources are not loaded using the multicore lib aware SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-726: --- Attachment: SOLR-726.patch A hackish work around to the class loader issue. This patch tries to use SolrResourceLoader#findClass to load the Driver class. It tries to use DriverManager#getConnection. If that fails, we try to instantiate the Driver class and use the Driver#connect method directly bypassing the DriverManager. This workaround is documented in the JdbcDataSource class. I will commit this shortly. > driver and datasources are not loaded using the multicore lib aware > SolrResourceLoader > -- > > Key: SOLR-726 > URL: https://issues.apache.org/jira/browse/SOLR-726 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Walter Ferrara >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-726.patch, SOLR-726.patch > > > see > http://www.nabble.com/dataimporthandler-and-mysql-connector-jar-td19146229.html > The jar containing the (jdbc) driver have to be present in the java > classpath. Putting it in coreX/lib or in the shared lib dir of a multicore > solr doesn't work -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-738) Facet counts over non-linear date intervals
Facet counts over non-linear date intervals --- Key: SOLR-738 URL: https://issues.apache.org/jira/browse/SOLR-738 Project: Solr Issue Type: New Feature Components: clients - php Affects Versions: 1.2 Reporter: screen Fix For: 1.2 Hi All, How can I generate facet counts over non-linear date intervals, for instance obtaining results from: "Last 7 days", "Last 30 days", "Last 90 days", "Last 6 months" ? I have tried everything mentioned in the docs but could not accomplish the above. Please help... TIA -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-738) Facet counts over non-linear date intervals
[ https://issues.apache.org/jira/browse/SOLR-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] screen updated SOLR-738: Description: Hi All, How can I generate facet counts over non-linear date intervals, for instance obtaining results from: "Last 7 days", "Last 30 days", "Last 90 days", "Last 6 months" ... ? I have tried everything mentioned in the docs but could not accomplish the above. Using Solr 1.2 with PhpSolrClient on PHP 5.25. Please help... TIA was: Hi All, How can I generate facet counts over non-linear date intervals, for instance obtaining results from: "Last 7 days", "Last 30 days", "Last 90 days", "Last 6 months" ? I have tried everything mentioned in the docs but could not accomplish the above. Please help... TIA > Facet counts over non-linear date intervals > --- > > Key: SOLR-738 > URL: https://issues.apache.org/jira/browse/SOLR-738 > Project: Solr > Issue Type: New Feature > Components: clients - php >Affects Versions: 1.2 >Reporter: screen > Fix For: 1.2 > > > Hi All, > How can I generate facet counts over non-linear date intervals, for instance > obtaining results from: "Last 7 days", "Last 30 days", "Last 90 days", "Last > 6 months" ... ? > I have tried everything mentioned in the docs but could not accomplish the > above. Using Solr 1.2 with PhpSolrClient on PHP 5.25. > Please help... > TIA -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
