[jira] Updated: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[ https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-517: Attachment: SOLR-517.patch updated for current trunk. > highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index > - > > Key: SOLR-517 > URL: https://issues.apache.org/jira/browse/SOLR-517 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2, 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch, > SOLR-517.patch, TestNegativeIdf.java > > > On un-optimized index, highlighter doesn't work with > hl.requireFieldMatch=true. > see: > http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html -- 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-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[
https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621687#action_12621687
]
koji edited comment on SOLR-517 at 8/11/08 9:27 PM:
--
Ok, I provided a Lucene program (TestNegativeIdf.java) to show negative idf.
To see negative idf, do not optimize() (do not uncomment the following line):
{code}
static void deleteDocument() throws IOException {
IndexWriter writer = new IndexWriter( dir, analyzer, false,
MaxFieldLength.LIMITED );
writer.deleteDocuments( new Term( "t_text1", "del" ) );
// To see negative idf, keep comment the following line
//writer.optimize();
writer.close();
}
{code}
You'll get a null fragment due to negative idf. Easiest way to avoid negative
idf, switch the scorer:
{code}
// This scorer can return negative idf -> null fragment
Scorer scorer = new QueryScorer( query, searcher.getIndexReader(), "t_text1" );
// This scorer doesn't use idf (patch version)
//Scorer scorer = new QueryScorer( query, "t_text1" );
{code}
was (Author: koji):
Ok, I provided a Lucene program to show negative idf.
To see negative idf, do not optimize() (do not uncomment the following line):
{code}
static void deleteDocument() throws IOException {
IndexWriter writer = new IndexWriter( dir, analyzer, false,
MaxFieldLength.LIMITED );
writer.deleteDocuments( new Term( "t_text1", "del" ) );
// To see negative idf, keep comment the following line
//writer.optimize();
writer.close();
}
{code}
You'll get a null fragment due to negative idf. Easiest way to avoid negative
idf, switch the scorer:
{code}
// This scorer can return negative idf -> null fragment
Scorer scorer = new QueryScorer( query, searcher.getIndexReader(),
"t_text1" );
// This scorer doesn't use idf (patch version)
//Scorer scorer = new QueryScorer( query, "t_text1" );
{code}
> highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
> -
>
> Key: SOLR-517
> URL: https://issues.apache.org/jira/browse/SOLR-517
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 1.2, 1.3
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch,
> TestNegativeIdf.java
>
>
> On un-optimized index, highlighter doesn't work with
> hl.requireFieldMatch=true.
> see:
> http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[
https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-517:
Attachment: TestNegativeIdf.java
Ok, I provided a Lucene program to show negative idf.
To see negative idf, do not optimize() (do not uncomment the following line):
{code}
static void deleteDocument() throws IOException {
IndexWriter writer = new IndexWriter( dir, analyzer, false,
MaxFieldLength.LIMITED );
writer.deleteDocuments( new Term( "t_text1", "del" ) );
// To see negative idf, keep comment the following line
//writer.optimize();
writer.close();
}
{code}
You'll get a null fragment due to negative idf. Easiest way to avoid negative
idf, switch the scorer:
{code}
// This scorer can return negative idf -> null fragment
Scorer scorer = new QueryScorer( query, searcher.getIndexReader(),
"t_text1" );
// This scorer doesn't use idf (patch version)
//Scorer scorer = new QueryScorer( query, "t_text1" );
{code}
> highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
> -
>
> Key: SOLR-517
> URL: https://issues.apache.org/jira/browse/SOLR-517
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 1.2, 1.3
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch,
> TestNegativeIdf.java
>
>
> On un-optimized index, highlighter doesn't work with
> hl.requireFieldMatch=true.
> see:
> http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-586) Maven - Solr Artifact Publishing
[ https://issues.apache.org/jira/browse/SOLR-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621674#action_12621674 ] Craig McClanahan commented on SOLR-586: --- Hmm ... JIRA doesn't make it at all obvious that the previous comment refers to the attachment named even though they were uploaded together ... so this should clarify things. > Maven - Solr Artifact Publishing > > > Key: SOLR-586 > URL: https://issues.apache.org/jira/browse/SOLR-586 > Project: Solr > Issue Type: New Feature > Components: clients - java, contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Spencer Crissman >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-586-20080811-craigmcc.zip, solr-common.pom.xml, > solr-dih.pom.xml, solr-server.pom.xml, solr2mvn.sh, solrj.pom.xml > > > I know there is an issue open (SOLR-19) for getting a solr build going under > Maven. This issue differs from that in that it does not concern the build > process of the solr project, but rather simple dependency management for > maven projects that depend on the solr artifacts. I've outlined a way to > easily incorporate solrj + dependencies into your own maven projects, in > hopes that others doing this find it useful. > This issue's purpose is twofold: > 1) Let others know the process. > 2) Open the idea of whether this can be streamlined/incorporated into the > standard build in some manner. > Depending on Solrj in a Maven Project > 1) Build a 1.3 snapshot. > 1.1) Check out the code from http://svn.apache.org/repos/asf/lucene/solr/ > 1.2) Build using "ant dist" > 2) Install the artifacts into your maven repo, using the included pom files. > 2.1) Move to your dist/apache-solr-1.3-dev/dist directory. > 2.2) Copy the attached pom files into this directory. > 2.3) Install solr-common into your repo. > ex) mvn install:install-file -Dfile=apache-solr-common-1.3-dev.jar > -DpomFile=solr-common.pom.xml > 2.4) Install solrj into your repo. > ex) mvn install:install-file -Dfile=apache-solr-solrj-1.3-dev.jar > -DpomFile=solrj.pom.xml > 3) Use Solrj in your existing Maven projects by including it as a dependency > in your own pom.xml > > org.apache.lucene.solr > solrj > 1.3-SNAPSHOT > > > So given the above process, it seems like it would be relatively simple to > standardize this process by: > 1) Including the solr-common and solrj pom files w/ the dist. > 2) Automating the periodic installation of the artifacts to a central repo, > such as the ibiblio repo. > If those steps were performed, then creating a (maven) project based on solrj > would be super simple: just #3 from above. Since most custom developments > are probably for the clients, it seems like simplifying this would be a nice > step to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-586) Maven - Solr Artifact Publishing
[ https://issues.apache.org/jira/browse/SOLR-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig McClanahan updated SOLR-586: -- Attachment: SOLR-586-20080811-craigmcc.zip Heres a substantially updated version of the earlier attachments, based in large part on the approach the Lucene folks took (creds to them for doing the grunt work :-). To use it: * Install the Maven Ant Tasks in a place accessible to your Ant (see <http://maven.apache.org/ant-tasks.html> for more info). * Download and unzip the patch into the top level directory of your Solr source tree from SVN. This will create a "maven" subdirectory with the new files. * Execute "ant clean dist" to create the usual Solr artifacts. * Change directory to "maven", then execute "ant -f build-maven.xml" to create the Maven artifacts and install them on your local repository. This includes the Lucene variants checked in to the "lib" directory, but done in a way that won't interfere with Lucene's own artifacts when 2.4 goes final. Shalin, you're welcome to use whatever of this makes sense -- but this functionality scratched my own personal itch quite nicely (Maven based app that needed Solrj in embedded mode). > Maven - Solr Artifact Publishing > > > Key: SOLR-586 > URL: https://issues.apache.org/jira/browse/SOLR-586 > Project: Solr > Issue Type: New Feature > Components: clients - java, contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Spencer Crissman >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-586-20080811-craigmcc.zip, solr-common.pom.xml, > solr-dih.pom.xml, solr-server.pom.xml, solr2mvn.sh, solrj.pom.xml > > > I know there is an issue open (SOLR-19) for getting a solr build going under > Maven. This issue differs from that in that it does not concern the build > process of the solr project, but rather simple dependency management for > maven projects that depend on the solr artifacts. I've outlined a way to > easily incorporate solrj + dependencies into your own maven projects, in > hopes that others doing this find it useful. > This issue's purpose is twofold: > 1) Let others know the process. > 2) Open the idea of whether this can be streamlined/incorporated into the > standard build in some manner. > Depending on Solrj in a Maven Project > 1) Build a 1.3 snapshot. > 1.1) Check out the code from http://svn.apache.org/repos/asf/lucene/solr/ > 1.2) Build using "ant dist" > 2) Install the artifacts into your maven repo, using the included pom files. > 2.1) Move to your dist/apache-solr-1.3-dev/dist directory. > 2.2) Copy the attached pom files into this directory. > 2.3) Install solr-common into your repo. > ex) mvn install:install-file -Dfile=apache-solr-common-1.3-dev.jar > -DpomFile=solr-common.pom.xml > 2.4) Install solrj into your repo. > ex) mvn install:install-file -Dfile=apache-solr-solrj-1.3-dev.jar > -DpomFile=solrj.pom.xml > 3) Use Solrj in your existing Maven projects by including it as a dependency > in your own pom.xml > > org.apache.lucene.solr > solrj > 1.3-SNAPSHOT > > > So given the above process, it seems like it would be relatively simple to > standardize this process by: > 1) Including the solr-common and solrj pom files w/ the dist. > 2) Automating the periodic installation of the artifacts to a central repo, > such as the ibiblio repo. > If those steps were performed, then creating a (maven) project based on solrj > would be super simple: just #3 from above. Since most custom developments > are probably for the clients, it seems like simplifying this would be a nice > step to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[ https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621671#action_12621671 ] Mark Miller commented on SOLR-517: -- Yeah, I had tried to turn that test into duplicate Lucene actions, and I couldn't replicate the problem. I will give it a whirl with solr when I get a chance. What values for totalNumDocs and docFreq are being used when you get the exception? I still don't see how your seeing a negative there... >>I'm afraid but I don't understand what you are saying (current trunk is using >>IndexReader method). If you use the IndexReader method token scoring is done using the idf formula - so you could do highlighting to varying degrees based on the score. There is a cost to this to get the info for the idf calculation and then also the calculation. If you don't use the IndexReader method, hits are just scored 1 or 0 pretty much. Thats all thats need for basic highlighting. But if no one is using the richer highlighting scores, you pay for nothing. > highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index > - > > Key: SOLR-517 > URL: https://issues.apache.org/jira/browse/SOLR-517 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2, 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch > > > On un-optimized index, highlighter doesn't work with > hl.requireFieldMatch=true. > see: > http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[ https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621667#action_12621667 ] Koji Sekiguchi commented on SOLR-517: - bq. Can you elaborate or make a test case? The patch includes a test case that indicates negative idf. If it doesn't please let me know so that I do double check. bq. Also, it doesn't appear helpful to use the IndexReader method unless you want to use those scores for other things (gradient highlighting etc). If you count on that, it can't be changed, if you don't it should be changed. I'm afraid but I don't understand what you are saying (current trunk is using IndexReader method). > highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index > - > > Key: SOLR-517 > URL: https://issues.apache.org/jira/browse/SOLR-517 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2, 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch > > > On un-optimized index, highlighter doesn't work with > hl.requireFieldMatch=true. > see: > http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html -- 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-683) Distributed Search / Shards Deadlock
Solr is not going to solve your DDOS attack issues no what whats put in place I would think - if it was made a focus to do that type of thing, it would be a bit like trying to hold the dyke together with your finger. What was the name of that Israeli security company that was DDOS'd out of existence... Cameron (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621642#action_12621642 ] Cameron commented on SOLR-683: -- We could up the number of threads in our container, but this does not completely resolve the issue, as any sort of denial of service attack would potentially cause this to happen with no possible way of recovery. I would agree that some sort of timeout would be needed to actually solve the issue. Distributed Search / Shards Deadlock Key: SOLR-683 URL: https://issues.apache.org/jira/browse/SOLR-683 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Environment: Linux jre1.6.0_05 8GB RAM 2 x 2 core AMD 2.4 Ghz 2 x 140GB disk Reporter: Cameron Assignee: Yonik Seeley Fix For: 1.3 Attachments: locked.log Per this discussion: http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html Solr seems to lock up when running distributed search on three servers, with all three using shards of each other. Thread dump attached.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621666#action_12621666 ] Lars Kotthoff commented on SOLR-683: Another way to handle this would be to configure the servlet container to reject incoming connections when all available threads are in use [1][2]. This will cause failed requests which could have been served after a short wait, but eliminates the deadlock problem. [1] http://docs.codehaus.org/display/JETTY/Configuring+Connectors [2] http://tomcat.apache.org/tomcat-6.0-doc/config/http.html > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[ https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621665#action_12621665 ] Mark Miller commented on SOLR-517: -- I'd be happy to fix this in the Lucene Highlighter, but what is actually going on to get a negative? By the look of it, I don't see possible values that could create a negative result - even if you allowed for negative inputs, you could still only get positives, NAN, or Infinity. Can you elaborate or make a test case? Also, it doesn't appear helpful to use the IndexReader method unless you want to use those scores for other things (gradient highlighting etc). If you count on that, it can't be changed, if you don't it should be changed. > highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index > - > > Key: SOLR-517 > URL: https://issues.apache.org/jira/browse/SOLR-517 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2, 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-517.patch, SOLR-517.patch, SOLR-517.patch > > > On un-optimized index, highlighter doesn't work with > hl.requireFieldMatch=true. > see: > http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621642#action_12621642 ] Cameron commented on SOLR-683: -- We could up the number of threads in our container, but this does not completely resolve the issue, as any sort of denial of service attack would potentially cause this to happen with no possible way of recovery. I would agree that some sort of timeout would be needed to actually solve the issue. > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- 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-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621633#action_12621633
]
hossman edited comment on SOLR-689 at 8/11/08 3:33 PM:
bq. I just wanted to know if there were preferences regarding "grouping" them
under a "properties" tag or not. (Much like having or not to group
cores)
i don't really have an opinion on that ... to my mind: isn't
needed ... grouping multiple tags into makes sense to segregate
their configuration from anything else that might go in the file (particularly
since the adminPath is specific to the ) ... the declarations
would be applicable to whatever context they are in right? so introducing a new
context would be ... odd.
bq. I could prepare a new version of the solr-646 patch (and add a persist test
including properties).
I'm not sure what the time frame is for SOLR-646, but i ment it would be nice
to have a persistence test that worked against the trunk as it is right now, to
prove that the behavior doesn't break when the SOLR-689.patch is applied. (ie:
commit a persistence test first, then commit SOLR-689.patch; worry about
SOLR-646 and any changes it makes separately)
was (Author: hossman):
bq. I just wanted to know if there were preferences regarding "grouping"
them under a "properties" tag or not. (Much like having or not to group
cores)
i don't really have an opinion on that ... to my mind: isn't
needed ... grouping multiple tags into makes sense to segregate
their configuration from anything else that might go in the file (particularly
since the adminPath is specific to the ) ... the declarations
would be applicable to whatever context they are in right? so introducing a new
context would be ... odd.
bq. I could prepare a new version of the solr-646 patch (and add a persist test
including properties). I'm not sure what the time frame is for SOLR-646, but i
ment it would be nice to have a persistence test that worked against the trunk
as it is right now, to prove that the behavior doesn't break when the
SOLR-689.patch is applied. (ie: commit a persistence test first, then commit
SOLR-689.patch; worry about SOLR-646 and any changes it makes separately)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621633#action_12621633
]
Hoss Man commented on SOLR-689:
---
bq. I just wanted to know if there were preferences regarding "grouping" them
under a "properties" tag or not. (Much like having or not to group
cores)
i don't really have an opinion on that ... to my mind: isn't
needed ... grouping multiple tags into makes sense to segregate
their configuration from anything else that might go in the file (particularly
since the adminPath is specific to the ) ... the declarations
would be applicable to whatever context they are in right? so introducing a new
context would be ... odd.
bq. I could prepare a new version of the solr-646 patch (and add a persist test
including properties). I'm not sure what the time frame is for SOLR-646, but i
ment it would be nice to have a persistence test that worked against the trunk
as it is right now, to prove that the behavior doesn't break when the
SOLR-689.patch is applied. (ie: commit a persistence test first, then commit
SOLR-689.patch; worry about SOLR-646 and any changes it makes separately)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-647: --- Attachment: solr-647.patch fixed 1.6 dependency (sorry & thanks Grant); updated to trunk; fixed a bug in SolrDispatchFilter (Multicore.getAdminCore can return a null core); introduced calls to acquire/release instead and modified EmbeddedSolrServer (for completeness). > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-647: --- Comment: was deleted > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621616#action_12621616 ] Yonik Seeley commented on SOLR-683: --- bq. So this seems to be a container level issue, not a Solr issue? Yes and no... it's not a low-level solr bug, and it can be solved by upping the number of concurrent threads or http requests in the container. But if we could set a read timeout on shard requests, we could also prevent a hard deadlock and return an error instead. In any case, we should increase the number of threads in the example jetty config and document this issue. > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621612#action_12621612 ] Yonik Seeley commented on SOLR-683: --- I duplicated a deadlock with two shards with 1000 client threads making requests. When I changed the maxThreads parameter from 250 to 1 (in jetty.xml), the deadlocks went away... I was able to run through 1M requests. > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621602#action_12621602 ] Henri Biestro commented on SOLR-647: Sorry & thanks Grant. > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621598#action_12621598 ] Grant Ingersoll commented on SOLR-647: -- But, I changed it to awaitTermination(60, TimeUnit.SECONDS) and that's just fine... > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621597#action_12621597 ] Grant Ingersoll commented on SOLR-647: -- This doesn't compile. The TimeUnit.MINUTES in SolrCoreTest is a 1.6 constant. > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621594#action_12621594 ] Cameron commented on SOLR-683: -- So this seems to be a container level issue, not a Solr issue? > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-683) Distributed Search / Shards Deadlock
[ https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621584#action_12621584 ] Yonik Seeley commented on SOLR-683: --- Here's the problem: deadlock is possible when the max number of concurrent HTTP requests is less than the number of possible HTTP requests (from both top-level clients, and by other shards). Consider the simplest case of two shards, each with just a single thread dedicated to handling incoming HTTP requests. A top-level request comes into each shard, and each shard queries the other. The second request to each shard blocks because the first thread has not yet completed. Deadlock. > Distributed Search / Shards Deadlock > > > Key: SOLR-683 > URL: https://issues.apache.org/jira/browse/SOLR-683 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Linux > jre1.6.0_05 > 8GB RAM > 2 x 2 core AMD 2.4 Ghz > 2 x 140GB disk >Reporter: Cameron >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: locked.log > > > Per this discussion: > http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html > Solr seems to lock up when running distributed search on three servers, with > all three using shards of each other. Thread dump attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-489. -- Resolution: Fixed Committed revision 684908. Thanks Sean and Lars > Added @deprecation Javadoc comments > --- > > Key: SOLR-489 > URL: https://issues.apache.org/jira/browse/SOLR-489 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Sean Timm >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.3 > > Attachments: deprecationDocumentation.patch, SOLR-489.patch, > SOLR-489.patch, SOLR-489.patch, SOLR-489.patch > > > In a number of files, @Deprecation annotations were added without > accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-489: Assignee: Grant Ingersoll (was: Mike Klaas) > Added @deprecation Javadoc comments > --- > > Key: SOLR-489 > URL: https://issues.apache.org/jira/browse/SOLR-489 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Sean Timm >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.3 > > Attachments: deprecationDocumentation.patch, SOLR-489.patch, > SOLR-489.patch, SOLR-489.patch, SOLR-489.patch > > > In a number of files, @Deprecation annotations were added without > accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621570#action_12621570
]
Henri Biestro commented on SOLR-689:
HossMan; I understand, my question was just syntactical.
The patch today does accomodate properties created at the solr (aka multicore)
& core levels (which allows a core to override "global" defaults) .
I just wanted to know if there were preferences regarding "grouping" them under
a "properties" tag or not. (Much like having or not to group cores) so
I could prepare a new version of the solr-646 patch (and add a persist test
including properties).
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
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-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621539#action_12621539
]
hossman edited comment on SOLR-689 at 8/11/08 11:35 AM:
-
Patch updated to reflect recent discussion and fix bug -Henri- (Koji) noticed
about generating completely invalid XML in the persist method. -- we clearly
don't have anything testing that.
I'd like to commit this tonight (in about 8 or 9 hours).
Before i do: would someone who knows more about the "multicore persistence"
mind writing a test for that? It can be, and probably should be, independent
from this patch, but if you attach it here i'll commit as well
was (Author: hossman):
Patch updated to reflect recent discussion and fix bug Henri noticed about
generating completely invalid XML in the persist method. -- we clearly don't
have anything testing that.
I'd like to commit this tonight (in about 8 or 9 hours).
Before i do: would someone who knows more about the "multicore persistence"
mind writing a test for that? It can be, and probably should be, independent
from this patch, but if you attach it here i'll commit as well
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621541#action_12621541
]
Hoss Man commented on SOLR-689:
---
bq. Regarding this issue wrt solr-646, what would be the preferred syntax to
declare properties:
Henri: I don't think anything in this issue really impacts the semantics of
SOLR-646, it's a question of intent: if the intent is to declare properties
that are valid anywhere in the file, then they should be children of the
tag. if the intent is to create properties that apply to all cores, but can't
be used elsewhere in the solr.xml, they should be in the tag. we could
have both, or just one depending on the use cases people have identified.
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-689:
--
Attachment: SOLR-689.patch
Patch updated to reflect recent discussion and fix bug Henri noticed about
generating completely invalid XML in the persist method. -- we clearly don't
have anything testing that.
I'd like to commit this tonight (in about 8 or 9 hours).
Before i do: would someone who knows more about the "multicore persistence"
mind writing a test for that? It can be, and probably should be, independent
from this patch, but if you attach it here i'll commit as well
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch, SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-575) Highlighting spans should merge across phrase query
[ https://issues.apache.org/jira/browse/SOLR-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621525#action_12621525 ] Mark Miller commented on SOLR-575: -- With the current API, I just don't see this happening. Tokens are given one at a time to be 'lit and returned - these formatted pieces are used to build up the fragments. Even trying to play tricks, I just don't think this issue is cleanly doable. With an alternate approach (one that didn't hand off individual tokens for highlighting) its easy enough, but I don't see the approach changing soon. It would almost be less of a hassle, if for some reason you really needed this, to just post process and merge continuous spans with regex or something. You still have the issue of stopwords that are not 'lit, etc but they are a lot easier to overcome than the API limitations of the Highlighter framework. > Highlighting spans should merge across phrase query > --- > > Key: SOLR-575 > URL: https://issues.apache.org/jira/browse/SOLR-575 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.2 >Reporter: Brian Whitman > > Somewhat related to but separate from SOLR-553, > It would be nice if the highlighter component "joined" the formatter tags > across an entire PhraseQuery. > e.g. > Lights (Live) : I Love You But > I've Chosen Darkness : > should really be > Lights (Live) : I Love You But I've Chosen Darkness : > assuming the query that generated these fragments was "I Love You But I've > Chosen Darkness" > I assume there's issues with stopwords (the But in the name was not formatted) -- 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-690) English Number Filter
These can be done w/ Synonyms, too On Aug 11, 2008, at 12:34 PM, Ronald Braun (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621494 #action_12621494 ] Ronald Braun commented on SOLR-690: --- It'd be nice to add in ordinals (e.g., 1st = first, 2nd = second, etc.) if this progresses. And this might be a bigger stretch (but just to round out some of the number issues that have come up for us): conversion of roman numerals (e.g., World War II = World War Two). Maybe this is better accomplished by an earlier roman numeral to cardinal numeral filter. English Number Filter - Key: SOLR-690 URL: https://issues.apache.org/jira/browse/SOLR-690 Project: Solr Issue Type: New Feature Components: search Reporter: Ryan McKinley Priority: Minor Attachments: EnglishNumberFilter.java This is (the start) of a Filter that converts numbers to the english equivolent. That is 0=zero, 11=eleven, 26="twenty six" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Grant Ingersoll http://www.lucidimagination.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ
[jira] Commented: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621511#action_12621511
]
Henri Biestro commented on SOLR-689:
Regarding this issue wrt solr-646, what would be the preferred syntax to
declare properties:
Shoud we have a ... tag to declare them in solr & in
core or only in solr ?
How about the following example:
{code:xml}
core-122
core-123
solr.DirectUpdateHandler2
solr.DirectUpdateHandler2
{code}
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-690) English Number Filter
[ https://issues.apache.org/jira/browse/SOLR-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621494#action_12621494 ] Ronald Braun commented on SOLR-690: --- It'd be nice to add in ordinals (e.g., 1st = first, 2nd = second, etc.) if this progresses. And this might be a bigger stretch (but just to round out some of the number issues that have come up for us): conversion of roman numerals (e.g., World War II = World War Two). Maybe this is better accomplished by an earlier roman numeral to cardinal numeral filter. > English Number Filter > - > > Key: SOLR-690 > URL: https://issues.apache.org/jira/browse/SOLR-690 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Ryan McKinley >Priority: Minor > Attachments: EnglishNumberFilter.java > > > This is (the start) of a Filter that converts numbers to the english > equivolent. That is 0=zero, 11=eleven, 26="twenty six" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621470#action_12621470 ] Matthias Epheser commented on SOLR-236: --- I just tried to apply the last patch and ran into 2 issues: First: The new getDocListAndSet(Query query, List..) method in SolrIndexSearcher calls the getDocListC(..) method using the old signature. I changed the call to the new signature and it worked very well: DocListAndSet ret = new DocListAndSet(); QueryResult queryResult = new QueryResult(); queryResult.setDocListAndSet(ret); queryResult.setPartialResults(false); QueryCommand queryCommand = new QueryCommand(); queryCommand.setQuery(query); queryCommand.setFilterList(filterList); queryCommand.setFilter(docSet); queryCommand.setSort(lsort); queryCommand.setOffset(offset); queryCommand.setLen(len); queryCommand.setFlags(flags |= GET_DOCSET); getDocListC(queryResult, queryCommand); Second: After adding more docs (~3000), I got an Exception in SolrIndexSearcher at line ~1300: qr.setDocSet(filter == null ? qDocSet : qDocSet.intersection(filter)); As the NegotiatedDocSet doesn't implement the iterator() function, this call lead to an Unsupported Operation exception. I just naively tried to implement this funtion using "return source.iterator()". Works fine for me. As the first issue is very clear, I wanted to check my approach for the second one before I post a patch. Maybe there are some side effects that I missed. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller >Assignee: Otis Gospodnetic > Attachments: field-collapsing-extended-592129.patch, > field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-690) English Number Filter
[ https://issues.apache.org/jira/browse/SOLR-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621432#action_12621432 ] Grant Ingersoll commented on SOLR-690: -- Note, Lucene has a English class in the test source that does the underlying, but not in a Filter. Just FYI > English Number Filter > - > > Key: SOLR-690 > URL: https://issues.apache.org/jira/browse/SOLR-690 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Ryan McKinley >Priority: Minor > Attachments: EnglishNumberFilter.java > > > This is (the start) of a Filter that converts numbers to the english > equivolent. That is 0=zero, 11=eleven, 26="twenty six" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rename multicore.xml ?
Let us have another JIRA issue for spring specific discussions. Let us trash it out there so that all the points we make here do not get lost when we actually have to make that decision. I am suggesting this because , whenever we discuss something something related to config this crops up and hijacks the real issue. --Noble On Mon, Aug 11, 2008 at 3:17 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote: >> >> I don't really drink from the "Spring would solve all our config/init >> problems" Kool-Aid > > Me neither, even though I'm a proponent of Solr aiming in that direction. > In fact, I think Spring has the potential to make it much more > convoluted/complicated to configure Solr (depending on how it's done). > > Spring-centric thinking benefits Solr by aiding in the design of things like > IndexSchema and SolrConfig - such that they would not have a > dependency/requirement that XML be involved at all. > > Springifying Solr doesn't mean littering Solr with Spring dependencies - it > really should be vastly cleaner than that, such that Spring is NOT required > to configure Solr at all (and this is the design benefit I see possible). > > I'd really love to see Solr get _out_ of dealing with configuration so > directly instead spending our time on ugly tangential stuff. > >Erik > > -- --Noble Paul
Re: Rename multicore.xml ?
On Aug 11, 2008, at 5:47 AM, Erik Hatcher wrote: On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote: I don't really drink from the "Spring would solve all our config/init problems" Kool-Aid Me neither, even though I'm a proponent of Solr aiming in that direction. In fact, I think Spring has the potential to make it much more convoluted/complicated to configure Solr (depending on how it's done). Yeah, I think we should choose the more complicated, convoluted route... :-) Spring-centric thinking benefits Solr by aiding in the design of things like IndexSchema and SolrConfig - such that they would not have a dependency/requirement that XML be involved at all. Springifying Solr doesn't mean littering Solr with Spring dependencies - it really should be vastly cleaner than that, such that Spring is NOT required to configure Solr at all (and this is the design benefit I see possible). Yes, this is how I see it too. I don't think we need all of Spring's extra layers (MVC, JDBC, etc). I think the IOC layer, means we don't need Spring at all if one wants to wire things up themselves. Yet, many people clearly want XML config, so in my mind, Spring brings some standardization to the game and gets us out of the config game and allows us to focus on actually improving Solr's search capabilities instead of having a gazillion different ways to init an object. -Grant
Re: Rename multicore.xml ?
On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote: I don't really drink from the "Spring would solve all our config/init problems" Kool-Aid Me neither, even though I'm a proponent of Solr aiming in that direction. In fact, I think Spring has the potential to make it much more convoluted/complicated to configure Solr (depending on how it's done). Spring-centric thinking benefits Solr by aiding in the design of things like IndexSchema and SolrConfig - such that they would not have a dependency/requirement that XML be involved at all. Springifying Solr doesn't mean littering Solr with Spring dependencies - it really should be vastly cleaner than that, such that Spring is NOT required to configure Solr at all (and this is the design benefit I see possible). I'd really love to see Solr get _out_ of dealing with configuration so directly instead spending our time on ugly tangential stuff. Erik
[jira] Commented: (SOLR-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621389#action_12621389
]
Koji Sekiguchi commented on SOLR-689:
-
bq. MultiCore.java config persistence writes info out to solr.xml and includes
root tag
{code}
writer.write("\n");
writer.write("\n");
{code}
should be:
{code}
writer.write("\n");
writer.write("\n");
{code}
:)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
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-689) rename multicore.xml solr.xml
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621389#action_12621389
]
koji edited comment on SOLR-689 at 8/11/08 2:33 AM:
--
bq. MultiCore.java config persistence writes info out to solr.xml and includes
root tag
{code}
writer.write("\n");
writer.write("\n");
{code}
should be:
{code}
writer.write("\n");
writer.write("\n");
{code}
:)
was (Author: koji):
bq. MultiCore.java config persistence writes info out to solr.xml and
includes root tag
{code}
writer.write("\n");
writer.write("\n");
{code}
should be:
{code}
writer.write("\n");
writer.write("\n");
{code}
:)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-689.patch
>
>
> Per mailing list discussion (see link below) it seems prudent to rename
> multicore.xml to solr.xml prior to the 1.3 release.
> short summary of the main motivations for doing this...
> {noformat}
>1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
>2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
> {noformat}
> General consensus of the thread so far seems to be that this is a good idea,
> and gives us more options for the future.
> http://www.nabble.com/Rename-multicore.xml---to18877268.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #525
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/525/changes
