[jira] Created: (SOLR-1206) Default ping is not useful
Default ping is not useful -- Key: SOLR-1206 URL: https://issues.apache.org/jira/browse/SOLR-1206 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Environment: Debian linux / jetty Reporter: Brian Whitman Priority: Minor We recently had a solr server go down as the underlying disk (where the data was) stopped responding. The server was still running and the admin GUI worked, as did the ping query. But any actual query (like select?q=*:*) would hang indefinitely. I know that you can modify the ping query to be more robust, but I would like to suggest that the default shipping ping tries to access data, as I imagine that's what your average user is testing when they "ping solr" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1034) ClientUtils.escapeQuery should escape ;
[ https://issues.apache.org/jira/browse/SOLR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-1034: Attachment: SOLR-ESCAPE.patch Patch to escape ; > ClientUtils.escapeQuery should escape ; > --- > > Key: SOLR-1034 > URL: https://issues.apache.org/jira/browse/SOLR-1034 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.4 > Environment: all >Reporter: Brian Whitman >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-ESCAPE.patch > > > The ClientUtils escapeQueryChars does not escape a ; symbol. This causes some > unexpected lexical errors when parsing query strings with ; in them. > See > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200902.mbox/%3cdbd9700a0902231722n5db79dc0u7363603f930be...@mail.gmail.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1034) ClientUtils.escapeQuery should escape ;
ClientUtils.escapeQuery should escape ; --- Key: SOLR-1034 URL: https://issues.apache.org/jira/browse/SOLR-1034 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.4 Environment: all Reporter: Brian Whitman Priority: Minor Fix For: 1.4 The ClientUtils escapeQueryChars does not escape a ; symbol. This causes some unexpected lexical errors when parsing query strings with ; in them. See http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200902.mbox/%3cdbd9700a0902231722n5db79dc0u7363603f930be...@mail.gmail.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[ https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-659: --- Attachment: SOLR-659.patch New patch syncs w/ trunk > Explicitly set start and rows per shard for more efficient bulk queries > across distributed Solr > --- > > Key: SOLR-659 > URL: https://issues.apache.org/jira/browse/SOLR-659 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Minor > Fix For: 1.4 > > Attachments: shards.start_rows.patch, SOLR-659.patch > > > The default behavior of setting start and rows on distributed solr (SOLR-303) > is to set start at 0 across all shards and set rows to start+rows across each > shard. This ensures all results are returned for any arbitrary start and rows > setting, but during "bulk queries" (where start is incrementally increased > and rows is kept consistent) the client would need finer control of the > per-shard start and rows parameter as retrieving many thousands of documents > becomes intractable as start grows higher. > Attaching a patch that creates a &shards.start and &shards.rows parameter. If > used, the logic that sets rows to start+rows per shard is overridden and each > shard gets the exact start and rows set in shards.start and shards.rows. The > client will receive up to shards.rows * nShards results and should set rows > accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-705) Distributed search should optionally return docID->shard map
[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671175#action_12671175
]
Brian Whitman commented on SOLR-705:
The latest patch doesn't seem to compile anymore, I get:
{{{
compile-solrj:
[javac] Compiling 1 source file to
/Users/bwhitman/outside/solr-trunk/build/solrj
[javac]
/Users/bwhitman/outside/solr-trunk/src/common/org/apache/solr/common/SolrDocument.java:50:
cannot assign a value to final variable _fields
[javac] _fields = new LinkedHashMap();
[javac] ^
}}}
> Distributed search should optionally return docID->shard map
>
>
> Key: SOLR-705
> URL: https://issues.apache.org/jira/browse/SOLR-705
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.4
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch,
> SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard
> mapping in the response. Without it, updating/deleting documents when the #
> of shards is variable is hard. We currently set this with a special
> requestHandler that filters /update and inserts the shard as a field in the
> index but it would be better if the shard location came back in the query
> response outside of the index.
--
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-705) Distributed search should optionally return docID->shard map
[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671175#action_12671175
]
bwhitman edited comment on SOLR-705 at 2/6/09 7:59 AM:
The latest patch doesn't seem to compile anymore, I get:
{{
compile-solrj:
[javac] Compiling 1 source file to
/Users/bwhitman/outside/solr-trunk/build/solrj
[javac]
/Users/bwhitman/outside/solr-trunk/src/common/org/apache/solr/common/SolrDocument.java:50:
cannot assign a value to final variable _fields
[javac] _fields = new LinkedHashMap();
[javac] ^
}}
was (Author: bwhitman):
The latest patch doesn't seem to compile anymore, I get:
{{{
compile-solrj:
[javac] Compiling 1 source file to
/Users/bwhitman/outside/solr-trunk/build/solrj
[javac]
/Users/bwhitman/outside/solr-trunk/src/common/org/apache/solr/common/SolrDocument.java:50:
cannot assign a value to final variable _fields
[javac] _fields = new LinkedHashMap();
[javac] ^
}}}
> Distributed search should optionally return docID->shard map
>
>
> Key: SOLR-705
> URL: https://issues.apache.org/jira/browse/SOLR-705
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.4
>
> Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch,
> SOLR-705.patch
>
>
> SOLR-303 queries with &shards parameters set need to return the dociD->shard
> mapping in the response. Without it, updating/deleting documents when the #
> of shards is variable is hard. We currently set this with a special
> requestHandler that filters /update and inserts the shard as a field in the
> index but it would be better if the shard location came back in the query
> response outside of the index.
--
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=12626324#action_12626324 ] Brian Whitman commented on SOLR-733: We also had to do this to write a requesthandler that maintains original dates on overwrite adds. But then I found this: http://wiki.apache.org/solr/UpdateRequestProcessor - does the updateRequestProcessor solve your problem? > 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 > Fix For: 1.3 > > > 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-705) Distributed search should optionally return docID->shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623684#action_12623684 ] Brian Whitman commented on SOLR-705: Well, can you filter/query/sort by the contents of this "shard" field? If not, it doesn't belong in the doc block, IMO > Distributed search should optionally return docID->shard map > > > Key: SOLR-705 > URL: https://issues.apache.org/jira/browse/SOLR-705 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: all >Reporter: Brian Whitman > Fix For: 1.4 > > Attachments: SOLR-705.patch > > > SOLR-303 queries with &shards parameters set need to return the dociD->shard > mapping in the response. Without it, updating/deleting documents when the # > of shards is variable is hard. We currently set this with a special > requestHandler that filters /update and inserts the shard as a field in the > index but it would be better if the shard location came back in the query > response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-705) Distributed search should optionally return docID->shard map
Distributed search should optionally return docID->shard map Key: SOLR-705 URL: https://issues.apache.org/jira/browse/SOLR-705 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Fix For: 1.4 SOLR-303 queries with &shards parameters set need to return the dociD->shard mapping in the response. Without it, updating/deleting documents when the # of shards is variable is hard. We currently set this with a special requestHandler that filters /update and inserts the shard as a field in the index but it would be better if the shard location came back in the query response outside of the index. -- 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=12622695#action_12622695 ] Brian Whitman commented on SOLR-575: Sure, post-processing is somewhat easy, except for stopwords (note the But in the example) -- it's just one of those quality-of-life concerns :) > 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 >Priority: Minor > > 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.
[jira] Commented: (SOLR-566) Incorporate Lucene's CheckIndex tool into Solr
[ https://issues.apache.org/jira/browse/SOLR-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619738#action_12619738 ] Brian Whitman commented on SOLR-566: -1 on running it on startup with any default. To be specific on mark's "forever," I killed one that was actively processing index files after 12 hours (it wasn't hung or anything) > Incorporate Lucene's CheckIndex tool into Solr > -- > > Key: SOLR-566 > URL: https://issues.apache.org/jira/browse/SOLR-566 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > Not sure how to just yet, but I think it would be good to somehow incorporate > Lucene's CheckIndex tool into Solr. I imagine it can be done nicely through > the admin, but I suspect it makes sense to also do it on startup or even as a > request handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-664) Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in query
[ https://issues.apache.org/jira/browse/SOLR-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman resolved SOLR-664. Resolution: Invalid > Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in > query > --- > > Key: SOLR-664 > URL: https://issues.apache.org/jira/browse/SOLR-664 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 >Reporter: Brian Whitman > Fix For: 1.3 > > > Query: q=+content:"a b c" > +type:web&hl.simple.pre=&hl.simple.post=&highlight=true&hl.fl=content > Returns docs like: > a b c web > Highlighter should only return fragments matched by the field denoted in the > highlight. > Happens whether or not usePhraseHighlighter=true or not. (SOLR-553) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-664) Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in query
[ https://issues.apache.org/jira/browse/SOLR-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617405#action_12617405 ] Brian Whitman commented on SOLR-664: Ah, missed that one. Any reason this is not on by default? Does it alter results in any meaningful way? > Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in > query > --- > > Key: SOLR-664 > URL: https://issues.apache.org/jira/browse/SOLR-664 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 >Reporter: Brian Whitman > Fix For: 1.3 > > > Query: q=+content:"a b c" > +type:web&hl.simple.pre=&hl.simple.post=&highlight=true&hl.fl=content > Returns docs like: > a b c web > Highlighter should only return fragments matched by the field denoted in the > highlight. > Happens whether or not usePhraseHighlighter=true or not. (SOLR-553) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-664) Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in query
Highlighter (maybe phraseHighlighter) is highlighting non-highlight fields in query --- Key: SOLR-664 URL: https://issues.apache.org/jira/browse/SOLR-664 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.3 Reporter: Brian Whitman Fix For: 1.3 Query: q=+content:"a b c" +type:web&hl.simple.pre=&hl.simple.post=&highlight=true&hl.fl=content Returns docs like: a b c web Highlighter should only return fragments matched by the field denoted in the highlight. Happens whether or not usePhraseHighlighter=true or not. (SOLR-553) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[
https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616903#action_12616903
]
Brian Whitman commented on SOLR-659:
An example of a bulk query using this patch. Without this patch such bulk
queries will eventually time out or cause exceptions in the server as too much
data is passed back and forth.
{code:java}
public SolrDocumentList blockQuery(SolrQuery q, int blockSize, int maxResults) {
SolrDocumentList allResults = new SolrDocumentList();
if(blockSize > maxResults) { blockSize = maxResults; }
for(int i=0; i maxResults) { break; }
}
if(allResults.size() > maxResults) { break; }
}
return allResults;
}
{code}
> Explicitly set start and rows per shard for more efficient bulk queries
> across distributed Solr
> ---
>
> Key: SOLR-659
> URL: https://issues.apache.org/jira/browse/SOLR-659
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Brian Whitman
>Priority: Minor
> Fix For: 1.3
>
> Attachments: shards.start_rows.patch
>
>
> The default behavior of setting start and rows on distributed solr (SOLR-303)
> is to set start at 0 across all shards and set rows to start+rows across each
> shard. This ensures all results are returned for any arbitrary start and rows
> setting, but during "bulk queries" (where start is incrementally increased
> and rows is kept consistent) the client would need finer control of the
> per-shard start and rows parameter as retrieving many thousands of documents
> becomes intractable as start grows higher.
> Attaching a patch that creates a &shards.start and &shards.rows parameter. If
> used, the logic that sets rows to start+rows per shard is overridden and each
> shard gets the exact start and rows set in shards.start and shards.rows. The
> client will receive up to shards.rows * nShards results and should set rows
> accordingly. This makes bulk queries across distributed solr possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr --- Key: SOLR-659 URL: https://issues.apache.org/jira/browse/SOLR-659 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Brian Whitman Priority: Minor Fix For: 1.3 Attachments: shards.start_rows.patch The default behavior of setting start and rows on distributed solr (SOLR-303) is to set start at 0 across all shards and set rows to start+rows across each shard. This ensures all results are returned for any arbitrary start and rows setting, but during "bulk queries" (where start is incrementally increased and rows is kept consistent) the client would need finer control of the per-shard start and rows parameter as retrieving many thousands of documents becomes intractable as start grows higher. Attaching a patch that creates a &shards.start and &shards.rows parameter. If used, the logic that sets rows to start+rows per shard is overridden and each shard gets the exact start and rows set in shards.start and shards.rows. The client will receive up to shards.rows * nShards results and should set rows accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[ https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-659: --- Attachment: shards.start_rows.patch Attaching patch. > Explicitly set start and rows per shard for more efficient bulk queries > across distributed Solr > --- > > Key: SOLR-659 > URL: https://issues.apache.org/jira/browse/SOLR-659 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Minor > Fix For: 1.3 > > Attachments: shards.start_rows.patch > > > The default behavior of setting start and rows on distributed solr (SOLR-303) > is to set start at 0 across all shards and set rows to start+rows across each > shard. This ensures all results are returned for any arbitrary start and rows > setting, but during "bulk queries" (where start is incrementally increased > and rows is kept consistent) the client would need finer control of the > per-shard start and rows parameter as retrieving many thousands of documents > becomes intractable as start grows higher. > Attaching a patch that creates a &shards.start and &shards.rows parameter. If > used, the logic that sets rows to start+rows per shard is overridden and each > shard gets the exact start and rows set in shards.start and shards.rows. The > client will receive up to shards.rows * nShards results and should set rows > accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614708#action_12614708 ] Brian Whitman commented on SOLR-303: Lars- I'm using the jetty that comes with solr-trunk, jetty-6.1.3. I found this: http://webteam.archive.org/jira/browse/HER-1173#action_14736 Which indicates the Jetty 6 concordant property is org.mortbay.jetty.Request.maxFormContentSize. I set that to 100, restarted my shards, and queries of &rows=4 works. So for those who have this problem, start jetty with: java -Dorg.mortbay.jetty.Request.maxFormContentSize=100 -jar start.jar I would suggest only that the jetty.xml included in the solr example somehow get this parameter hardcoded (I don't know how personally.) I understand this is not a solr issue but it does cause a non-obvious result to an obvious query. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614410#action_12614410 ] Brian Whitman commented on SOLR-303: My ids are 32-character MD5s, and the break happens around 23000 rows. The maxFormContentSize doesn't seem to make any difference whether I set it or not-- with it set at 0, -1, 1000 or not set at all I can query &rows=22300 but not &rows=22400. Obviously this is an edge case but I'm posting this here for the next person who runs into this... but since I can work around it I'll stop messing with it. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614397#action_12614397 ] Brian Whitman commented on SOLR-303: Yonik, sure-- but I think we should probably handle the case better than a 500 error. maybe a solr warning about per-shard row limits? Lars -- I am having trouble getting that maxFormContentSize property set. I am running jetty like: /usr/local/java/bin/java -Dorg.mortbay.http.HttpRequest.maxFormContentSize=100 -Xmx7000m -Xms1024m -jar start.jar (I've also tried 0 and -1, per the jetty docs this means "unlimited.") but the same distributed query gives the same error. How are you setting that property? > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- 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-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613969#action_12613969 ] bwhitman edited comment on SOLR-303 at 7/16/08 7:28 AM: - Getting "Form too large" from jetty while doing normal but large rows= (4) shards requests. Is this related to SOLR-612 ? Query was : http://x.x.x.x/solr/search?q=*:*&sort=indexed%20desc&fl=indexed&rows=4 , where x.x.x.x is a single shard and /search has the shards ivars mapped to it in solrconfig. (Sorry for the mess, but that's how it appears) Form_too_large__javalangIllegalStateException_ Form_too_large__at_orgmortbayjettyRequestextractParametersRequestjava1273__at_ orgmortbayjettyRequestgetParameterMapRequestjava650__at_ orgapachesolrrequestServletSolrParamsinitServletSolrParamsjava29__at_ orgapachesolrservletStandardRequestParserparseParamsAndFillStreamsSolrRequestParsersjava392__at_ orgapachesolrservletSolrRequestParsersparseSolrRequestParsersjava113__at_ orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava240__at_ orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_ orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_ orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_ orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_ orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_ orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_ orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_ orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_ orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_ orgmortbayjettyServerhandleServerjava285__at_ orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_ orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_ orgmortbayjettyHttpParserparseNextHttpParserjava641__at_ orgmortbayjettyHttpParserparseAvailableHttpParserjava202__at_ orgmortbayjettyHttpConnectionhandleHttpConnectionjava378__at_ orgmortbayjettybioSocketConnector$ConnectionrunSocketConnectorjava226__at_ orgmortbaythreadBoundedThreadPool$PoolThreadrunBoundedThreadPooljava442_ request: http://x.x.x.x.y/solr/select (ed: this was a different shard than the one I called) request: http://x.x.x.y/solr/select at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:343) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183) at org.apache.solr.handler.component.HttpCommComponent$1.call(SearchHandler.java:371) at org.apache.solr.handler.component.HttpCommComponent$1.call(SearchHandler.java:345) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) was (Author: bwhitman): Getting "Form too large" from jetty while doing normal but large rows= (4) shards requests. Is this related to SOLR-612 ? Query was : http://x.x.x.x/solr/search?q=*:*&sort=indexed%20desc&fl=indexed&rows=4 , where x.x.x.x is a single shard and /search has the shards ivars mapped to it in solrconfig. (Sorry for the mess, but that's how it appears) Form_too_large__javalangIllegalStateException_Form_too_large__at_orgmortbayjettyRequestextractParametersRequestjava1273__at_orgmortbayjettyRequestgetParameterMapRequestjava650__at_orgapachesolrrequestServletSolrParamsinitServletSolrParamsjava29__at_orgapachesolrservletStandardRequestParserparseParamsAndFillStreamsSolrRequestParsersjava392__at_orgapachesolrservletSolrRequestParsersparseSolrRequestParsersjava113__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava240__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_orgmortbayjettyhandlerHandlerWr
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613969#action_12613969 ] Brian Whitman commented on SOLR-303: Getting "Form too large" from jetty while doing normal but large rows= (4) shards requests. Is this related to SOLR-612 ? Query was : http://x.x.x.x/solr/search?q=*:*&sort=indexed%20desc&fl=indexed&rows=4 , where x.x.x.x is a single shard and /search has the shards ivars mapped to it in solrconfig. (Sorry for the mess, but that's how it appears) Form_too_large__javalangIllegalStateException_Form_too_large__at_orgmortbayjettyRequestextractParametersRequestjava1273__at_orgmortbayjettyRequestgetParameterMapRequestjava650__at_orgapachesolrrequestServletSolrParamsinitServletSolrParamsjava29__at_orgapachesolrservletStandardRequestParserparseParamsAndFillStreamsSolrRequestParsersjava392__at_orgapachesolrservletSolrRequestParsersparseSolrRequestParsersjava113__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava240__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_orgmortbayjettyServerhandleServerjava285__at_orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_orgmortbayjettyHttpParserparseNextHttpParserjava641__at_orgmortbayjettyHttpParserparseAvailableHttpParserjava202__at_orgmortbayjettyHttpConnectionhandleHttpConnectionjava378__at_orgmortbayjettybioSocketConnector$ConnectionrunSocketConnectorjava226__at_orgmortbaythreadBoundedThreadPool$PoolThreadrunBoundedThreadPooljava442_ request: http://x.x.x.x.y/solr/select (ed: this was a different shard than the one I called) request: http://x.x.x.y/solr/select at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:343) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183) at org.apache.solr.handler.component.HttpCommComponent$1.call(SearchHandler.java:371) at org.apache.solr.handler.component.HttpCommComponent$1.call(SearchHandler.java:345) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-612) solrj should (optionally?) use POST for queries
[
https://issues.apache.org/jira/browse/SOLR-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612560#action_12612560
]
Brian Whitman commented on SOLR-612:
Well then maybe I just don't understand how to do it right -- how do I tell
solrj to use post, for this example:
SolrServer s = new CommonsHttpSolrServer("http://localhost:8983/solr";);
SolrQuery q = new SolrQuery();
q.setQuery("type:dog");
QueryResponse qr = s.query(q);
Where in there would I set SolrRequest to use POST?
> solrj should (optionally?) use POST for queries
> ---
>
> Key: SOLR-612
> URL: https://issues.apache.org/jira/browse/SOLR-612
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.3
>
> Attachments: solrj-post.diff
>
>
> Can we make solrj always send post queries (or have it be an init-able
> option)?
> Jetty has some "problems" (in quotes because I don't know if it's really a
> problem) with long queries over GET:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL
> PROTECTED]
> Tiny patch attached that changes it and doesn't cause an exception on long
> queries in Jetty w/ solrj.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-303: --- Attachment: shards.start_rows.patch Attaching patch to add a &shards.start and &shards.rows optional parameter. If set, they override distributed search's intelligence on setting start and rows per shard. If you set &shards.start=10 and &shards.rows=10, each shard will be queried with &start=10 and &rows=10 and you'll get back N*10 results (set &rows on the main query to get it all.) [Not a java developer, my patch works but may violate good taste/style] > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611376#action_12611376 ] Brian Whitman commented on SOLR-303: Understood. Can I suggest a third alternative? two new params: named &d.rows and &d.start with the implication that these get sent unchanged to each of the shards. You may get back up to N*d.rows, where N is the # of shards. That leaves the paging management up to the client. Our use case is millions of documents across many shards, and we often do queries that are "get all document of type X." There may be 5m type X documents. Doing a &rows=500 is unpredictable so we've previously done a loop of incrementing start by a 1000 and getting 1000 rows each time. But with this distributed setup, each successive batch query takes slightly longer, and by the time we've gotten to the 5,001,000 batch queries are timing out and breaking anyway. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- 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-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607106#action_12607106
]
bwhitman edited comment on SOLR-303 at 7/7/08 2:57 PM:
Putting &debugQuery on a query with shards that returns 0 results will NPE:
(removing NPE code block so it stops wrapping the page)
was (Author: bwhitman):
Putting &debugQuery on a query with shards that returns 0 results will NPE:
{code}
INFO: webapp=/solr path=/select
params={shards=localhost:8983/solr,localhost:8984/solr,localhost:8985/solr,localhost:8986/solr&debugQuery=true&q=i_tag:894&rows=100}
status=500 QTime=8
Jun 22, 2008 12:45:38 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:133)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:257)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:965)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
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:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611368#action_12611368
]
Brian Whitman commented on SOLR-303:
Anyone notice something like this:
http://localhost:8983/solr/select?shards={4 shards}&q=*:*&start=5000&rows=1000
Seems to request &rows=6000 from all the shards? (likewise,
start=1&rows=1000 sends rows=11000 to all the shards?)
The shards all say:
INFO: webapp=/solr path=/select
params={fl=id,score&start=0&q=*:*&isShard=true&wt=javabin&fsv=true&rows=6000&version=2.2}
hits=6000 status=0 QTime=175
And the host I called select on says:
INFO: webapp=/solr path=/search params={start=5000&q=*:*&rows=1000} status=0
QTime=1192
And the QTime goes up the higher &start goes. (QTime for start=5000 was 200,
QTime for start=5 was 4500, start=50 had 35000!)
Bug or feature?
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-612) solrj should (optionally?) use POST for queries
solrj should (optionally?) use POST for queries --- Key: SOLR-612 URL: https://issues.apache.org/jira/browse/SOLR-612 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Fix For: 1.3 Attachments: solrj-post.diff Can we make solrj always send post queries (or have it be an init-able option)? Jetty has some "problems" (in quotes because I don't know if it's really a problem) with long queries over GET: http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL PROTECTED] Tiny patch attached that changes it and doesn't cause an exception on long queries in Jetty w/ solrj. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-612) solrj should (optionally?) use POST for queries
[ https://issues.apache.org/jira/browse/SOLR-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-612: --- Attachment: solrj-post.diff patch > solrj should (optionally?) use POST for queries > --- > > Key: SOLR-612 > URL: https://issues.apache.org/jira/browse/SOLR-612 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 > Environment: all >Reporter: Brian Whitman > Fix For: 1.3 > > Attachments: solrj-post.diff > > > Can we make solrj always send post queries (or have it be an init-able > option)? > Jetty has some "problems" (in quotes because I don't know if it's really a > problem) with long queries over GET: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL > PROTECTED] > Tiny patch attached that changes it and doesn't cause an exception on long > queries in Jetty w/ solrj. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607106#action_12607106
]
Brian Whitman commented on SOLR-303:
Putting &debugQuery on a query with shards that returns 0 results will NPE:
{code}
INFO: webapp=/solr path=/select
params={shards=localhost:8983/solr,localhost:8984/solr,localhost:8985/solr,localhost:8986/solr&debugQuery=true&q=i_tag:894&rows=100}
status=500 QTime=8
Jun 22, 2008 12:45:38 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:133)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:257)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:965)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
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:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607097#action_12607097 ] Brian Whitman commented on SOLR-303: If the user is going to be splitting their index over N shards, it's going to be crucial to have the distributed search (optionally) return the docid->shard map in the response. Is that tricky to add as part of this issue? > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605650#action_12605650 ] Brian Whitman commented on SOLR-303: When I give the following request: http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solr&q=woof With no server running on 8984 I get a error 500 (naturally.) But shouldn't there be an option to skip over servers that aren't responding or time out? Envisioning a scenario in which this is used to search across possibly redundant uniqueIDs and a server being down is not cause for exception. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597647#action_12597647 ] Brian Whitman commented on SOLR-553: just FYI, I've tested this on a much larger/realworld index and it works great. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman >Assignee: Otis Gospodnetic > Attachments: highlighttest.xml, Solr-553.patch, Solr-553.patch, > Solr-553.patch > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596915#action_12596915 ] Brian Whitman commented on SOLR-553: +1 on making it default if there was a phrasequery. The "old" way comes across as a bad bug if you're displaying the highlights for your search results. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml, Solr-553.patch > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596882#action_12596882 ] Brian Whitman commented on SOLR-553: Patch works for me on the highlighttest.xml. thanks Bojan!! > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml, Solr-553.patch > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-553: --- Description: http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html Say we search for the band "I Love You But I've Chosen Darkness" .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : I Love You But I've Chosen Darkness : But also returns unrelated snips from the same page: Black Francis Shop "I Think I Love You" A correct highlighter should not return snippets that do not match the phrase exactly. LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem from the Lucene end. Solr should get it too. Related: SOLR-575 was: http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html Say we search for the band "I Love You But I've Chosen Darkness" .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : I Love You But I've Chosen Darkness : But also returns unrelated snips from the same page: Black Francis Shop "I Think I Love You" A correct highlighter should only return Lights (Live) : I Love You But I've Chosen Darkness And no snippets that do not match the phrase exactly. LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem from the Lucene end. Solr should get it too. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-575) Highlighting spans should merge across phrase query
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.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596402#action_12596402 ] Brian Whitman commented on SOLR-553: Probably best to create a new ticket (if necessary) about the ax bx instead of ax bx problem. That highlights have incorrect matches is far worse. I'll adjust the problem description. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should only return > Lights (Live) : I Love You But I've Chosen Darkness > And no snippets that do not match the phrase exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-553: --- Attachment: highlighttest.xml Attaching a base test case document xml to post to the trunk solr example to see the problem. Steps to reproduce: 1) checkout solr-trunk 2) ant example 3) java -jar start.jar 4) post.sh highlighttest.xml 5) query: http://localhost:8983/solr/select?q=features:%22ax%20bx%20cx%22&hl=on&hl.fl=features&hl.fragsize=20&hl.snippets=10 Expected results: the only highlight snip results returned should be ax bx cx and nothing else. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should only return > Lights (Live) : I Love You But I've Chosen Darkness > And no snippets that do not match the phrase exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-553: --- Description: http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html Say we search for the band "I Love You But I've Chosen Darkness" .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : I Love You But I've Chosen Darkness : But also returns unrelated snips from the same page: Black Francis Shop "I Think I Love You" A correct highlighter should only return Lights (Live) : I Love You But I've Chosen Darkness And no snippets that do not match the phrase exactly. LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem from the Lucene end. Solr should get it too. was: http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html PhraseQueries like "A Long String" will return highlighting matches that only match "String" or "String Long" or any combination. We need them to return A Long String instead. LUCENE-794 seems to be added to trunk now and corrects it from their end. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should only return > Lights (Live) : I Love You But I've Chosen Darkness > And no snippets that do not match the phrase exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-553) Highlighter does not match phrase queries correctly
Highlighter does not match phrase queries correctly --- Key: SOLR-553 URL: https://issues.apache.org/jira/browse/SOLR-553 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.2 Environment: all Reporter: Brian Whitman http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html PhraseQueries like "A Long String" will return highlighting matches that only match "String" or "String Long" or any combination. We need them to return A Long String instead. LUCENE-794 seems to be added to trunk now and corrects it from their end. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-455) Better handling when index runs out of disk space
Better handling when index runs out of disk space - Key: SOLR-455 URL: https://issues.apache.org/jira/browse/SOLR-455 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2, 1.3 Environment: Linux/Debian etch Reporter: Brian Whitman We had an index run out of disk space. Queries work fine but commits return 500 doc counts differ for segment _18lu: fieldsReader shows 104 but segmentInfo shows 212 org.apache.lucene.index.CorruptIndexException: doc counts differ for segment _18lu: fieldsReader shows 104 but segmentInfo shows 212 at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:191) I've made room, restarted resin, and now solr won't start. No useful messages in the startup, just a [21:01:49.105] Could not start SOLR. Check solr/home property [21:01:49.105] java.lang.NullPointerException [21:01:49.105] at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:100) Solr should warn the user and/or refuse commits when the index nears the end of disk space -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-268) SimplePostTool should show Solr error, not just HTTP code
[ https://issues.apache.org/jira/browse/SOLR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-268: --- Attachment: post.jar.error.patch Attaching patch > SimplePostTool should show Solr error, not just HTTP code > - > > Key: SOLR-268 > URL: https://issues.apache.org/jira/browse/SOLR-268 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Trivial > Fix For: 1.3 > > Attachments: post.jar.error.patch > > > Tiny fix to have post.jar show the solr error message, not just a fatal error > when it gets a 400 HTTP code. There is probably a better way to do this but > this is how I did it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-268) SimplePostTool should show Solr error, not just HTTP code
SimplePostTool should show Solr error, not just HTTP code - Key: SOLR-268 URL: https://issues.apache.org/jira/browse/SOLR-268 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Brian Whitman Priority: Trivial Fix For: 1.3 Tiny fix to have post.jar show the solr error message, not just a fatal error when it gets a 400 HTTP code. There is probably a better way to do this but this is how I did it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
[ https://issues.apache.org/jira/browse/SOLR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman resolved SOLR-242. Resolution: Won't Fix > tr parameter implies XSL, no wt=xslt necessary > -- > > Key: SOLR-242 > URL: https://issues.apache.org/jira/browse/SOLR-242 > Project: Solr > Issue Type: Improvement >Reporter: Brian Whitman >Priority: Trivial > > Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the > XML from whichever response writer is being used gets parsed by the given > transform. The wt=xslt is somewhat redundant. And maybe change the tr > parameter to xslt. > Imagine in the future there's a response writer that outputs a different kind > of XML. That shouldn't preclude the use of a transform on top of that > response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-208) RSS feed XSL example
[ https://issues.apache.org/jira/browse/SOLR-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-208: --- Attachment: atom.xsl Adding atom.xsl (replaces rss.xsl) Changes: - Added apache header - Atom, not RSS 2.0 It validates on feedvalidator.org as atom 1.0 except for the link rel=self, since that's on localhost) > RSS feed XSL example > > > Key: SOLR-208 > URL: https://issues.apache.org/jira/browse/SOLR-208 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.2 >Reporter: Brian Whitman > Assigned To: Hoss Man >Priority: Trivial > Attachments: atom.xsl, rss.xsl > > > A quick .xsl file for transforming solr queries into RSS feeds. To get the > date and time in properly you'll need an XSL 2.0 processor, as in > http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the > example solr distribution in the nightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-208) RSS feed XSL example
[ https://issues.apache.org/jira/browse/SOLR-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497902 ] Brian Whitman commented on SOLR-208: Someone else questioned my choice of RSS spec last night. I don't want my tiny Solr contribution to become a political issue! +1 on noting that it's incomplete and will have to be changed for the user's specific scenario. I'll make it Atom. > RSS feed XSL example > > > Key: SOLR-208 > URL: https://issues.apache.org/jira/browse/SOLR-208 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.2 >Reporter: Brian Whitman > Assigned To: Hoss Man >Priority: Trivial > Attachments: rss.xsl > > > A quick .xsl file for transforming solr queries into RSS feeds. To get the > date and time in properly you'll need an XSL 2.0 processor, as in > http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the > example solr distribution in the nightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497312 ] Brian Whitman commented on SOLR-69: --- Also (sorry to keep commenting on this!) asking for fl=score doesn't work, I get this: java.lang.NullPointerException at org.apache.solr.search.DocSlice$1.score(DocSlice.java:117) at org.apache.solr.request.XMLWriter.writeDocList(XMLWriter.java:369) at org.apache.solr.request.XMLWriter.writeVal(XMLWriter.java:408) at org.apache.solr.request.XMLWriter.writeResponse(XMLWriter.java:126) at org.apache.solr.request.XMLResponseWriter.write(XMLResponseWriter.java:35) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:169) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) at com.caucho.util.ThreadPool.run(ThreadPool.java:442) at java.lang.Thread.run(Thread.java:619) if I do a query like /mlt?q=id:100&mlt.fl=content&fl=content,score If I take out the score from the fl it doesn't NPE. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497283 ] Brian Whitman commented on SOLR-69: --- The mlt.exclude is similar to what I'm looking for but an mlt.fq is generally more useful. Also, mlt.exclude does not seem to support more than a single term query, e.g. mlt.exclude=+type:AUTHOR +type:PUBLISHER still lets type:PUBLISHER through. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
[ https://issues.apache.org/jira/browse/SOLR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497179 ] Brian Whitman commented on SOLR-242: OK, I guess I am over-complicating by trying to simplify. XSLT to me seems like something that happens at the very end of everything, and the response writers seem to be a different "class" of things. But if tr is only used by xslt, shouldn't it be xslt.tr (to follow the standard, like json.nl?) Also, if wt=xslt is set but no tr=, what happens? > tr parameter implies XSL, no wt=xslt necessary > -- > > Key: SOLR-242 > URL: https://issues.apache.org/jira/browse/SOLR-242 > Project: Solr > Issue Type: Improvement >Reporter: Brian Whitman >Priority: Trivial > > Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the > XML from whichever response writer is being used gets parsed by the given > transform. The wt=xslt is somewhat redundant. And maybe change the tr > parameter to xslt. > Imagine in the future there's a response writer that outputs a different kind > of XML. That shouldn't preclude the use of a transform on top of that > response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497178 ] Brian Whitman commented on SOLR-69: --- R, one useful feature would be mlt.fq=query, where query is a filter query, like type:book. Or since we're moving to a solo handler for mlt, just supporting fq would be good. like /mlt?q=id:BOOK01&mlt.fl=contents&fq=type:BOOK (Because in a single solr instance you've got information about books & authors, and you only want the mlt results to be books.) > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
tr parameter implies XSL, no wt=xslt necessary -- Key: SOLR-242 URL: https://issues.apache.org/jira/browse/SOLR-242 Project: Solr Issue Type: Improvement Reporter: Brian Whitman Priority: Trivial Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the XML from whichever response writer is being used gets parsed by the given transform. The wt=xslt is somewhat redundant. And maybe change the tr parameter to xslt. Imagine in the future there's a response writer that outputs a different kind of XML. That shouldn't preclude the use of a transform on top of that response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497069 ] Brian Whitman commented on SOLR-69: --- Oof ryan, my apologies, I was running an older version of this patch. fl is listened to. This is an excellent job, btw, I love that you can hide the original response. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497022 ] Brian Whitman commented on SOLR-69: --- Ryan, it seems the handler doesn't listen to the fl parameter either in the result section or the morelikethis section. It always returns everything. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-208) RSS feed XSL example
[ https://issues.apache.org/jira/browse/SOLR-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496612 ] Brian Whitman commented on SOLR-208: I'm not involved or familiar with the RSS wars but I will say that this is a quick example of getting RSS out of Solr in the easiest possible way. It worked on every single browser and newsreader I tried it on. There's no reason we can't also include an atom_example.xsl as well. I don't understand why you would use GData for this at all, but i am probably out of my league there. +1 for adding except remove the XSL2.0 references, not worth the confusion, date handling is not necessary for the exampledocs test case. > RSS feed XSL example > > > Key: SOLR-208 > URL: https://issues.apache.org/jira/browse/SOLR-208 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.2 >Reporter: Brian Whitman > Assigned To: Hoss Man >Priority: Trivial > Attachments: rss.xsl > > > A quick .xsl file for transforming solr queries into RSS feeds. To get the > date and time in properly you'll need an XSL 2.0 processor, as in > http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the > example solr distribution in the nightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495393
]
Brian Whitman commented on SOLR-216:
I'm noticing that you are looking for
if not data.startswith('
040
now. I'm not too used to python to fix this properly at the moment.
> Improvements to solr.py
> ---
>
> Key: SOLR-216
> URL: https://issues.apache.org/jira/browse/SOLR-216
> Project: Solr
> Issue Type: Improvement
> Components: clients - python
>Affects Versions: 1.2
>Reporter: Jason Cater
>Priority: Trivial
> Attachments: solr.py
>
>
> I've taken the original solr.py code and extended it to include higher-level
> functions.
> * Requires python 2.3+
> * Supports SSL (https://) schema
> * Conforms (mostly) to PEP 8 -- the Python Style Guide
> * Provides a high-level results object with implicit data type conversion
> * Supports batching of update commands
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493835 ] Brian Whitman commented on SOLR-216: Hi Jason, this is really great. I had one small issue -- highlighting did not seem to work. I looked into your code and found you were using hi.fl and hi, not hl.fl and hl. Not sure if your solr expects hi, but mine expects hl. Once I changed line 453 & 457 to hl instead of hi it works fine. > Improvements to solr.py > --- > > Key: SOLR-216 > URL: https://issues.apache.org/jira/browse/SOLR-216 > Project: Solr > Issue Type: Improvement > Components: clients - python >Affects Versions: 1.2 >Reporter: Jason Cater >Priority: Trivial > Attachments: solr.py > > > I've taken the original solr.py code and extended it to include higher-level > functions. > * Requires python 2.3+ > * Supports SSL (https://) schema > * Conforms (mostly) to PEP 8 -- the Python Style Guide > * Provides a high-level results object with implicit data type conversion > * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-225) Customize fragmenter per requesthandler in solrconfig
Customize fragmenter per requesthandler in solrconfig - Key: SOLR-225 URL: https://issues.apache.org/jira/browse/SOLR-225 Project: Solr Issue Type: Improvement Reporter: Brian Whitman We definitely need an option to set the fragmenter class in solrconfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-212) Embeddable class to call solr directly
[
https://issues.apache.org/jira/browse/SOLR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Whitman updated SOLR-212:
---
Attachment: embeddedSolr.zip
I didn't have time to extract it from Cocoa/ObjC. Here is the xcode project
with everything anyway -- so right now you'll need OSX to try this out. This is
a very simple test of Ryan's SOLR-212 patch, it queries, adds a document and
commits, all without a web server! Let me know if you have any questions.
--brian
> Embeddable class to call solr directly
> --
>
> Key: SOLR-212
> URL: https://issues.apache.org/jira/browse/SOLR-212
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
> Assigned To: Ryan McKinley
>Priority: Minor
> Fix For: 1.2
>
> Attachments: embeddedSolr.zip, SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch
>
>
> For some embedded applications, it is useful to call solr without running an
> HTTP server. This class mimics the behavior you would get if you sent the
> request through an HTTP connection. It is designed to work nicely (ie
> simple) with JNI
> the main function is:
> public class DirectSolrConnection
> {
> String request( String pathAndParams, String body ) throws Exception
> {
> ...
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493185 ] Brian Whitman commented on SOLR-69: --- I've personally never understood the "more documents that don't match this query but are like the documents in this query" usage of SOLR-69. MLT results (to me) should be like any other result, except by querying by text you are querying by document ID. I'm confused as to how querying by query would work -- if a query for 'apache' returned 10 docs, would MLT work on each one and generate n more docs per doc? And would the original query results get returned? What's the ordering? But I do know that paging and faceting should definitely work on MLT results. (Ryan's patch seems to implement this but I haven't tested it.) MLT results should look and operate like any other results. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, > SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch, SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-212) Embeddable class to call solr directly
[
https://issues.apache.org/jira/browse/SOLR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492591
]
Brian Whitman commented on SOLR-212:
Am working on extracting it from Cocoa as we speak... watch this space!
> Embeddable class to call solr directly
> --
>
> Key: SOLR-212
> URL: https://issues.apache.org/jira/browse/SOLR-212
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
> Assigned To: Ryan McKinley
>Priority: Minor
> Fix For: 1.2
>
> Attachments: SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch
>
>
> For some embedded applications, it is useful to call solr without running an
> HTTP server. This class mimics the behavior you would get if you sent the
> request through an HTTP connection. It is designed to work nicely (ie
> simple) with JNI
> the main function is:
> public class DirectSolrConnection
> {
> String request( String pathAndParams, String body ) throws Exception
> {
> ...
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-212) Embeddable class to call solr directly
[
https://issues.apache.org/jira/browse/SOLR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492522
]
Brian Whitman commented on SOLR-212:
Since the main use case of SOLR-212 is to embed it in client applications, we
should be careful about logging. As of now SOLR-212 will spit stuff all over
stderr.
I suggest putting this
System.setProperty("java.util.logging.config.file",
instanceDir+"/conf/logging.properties");
near line 79 of DirectSolrConnection.java. That way, if a developer/user
chooses, they can put a logging.prop file in conf and set direct logging of
Solr requests either to their own application logs or a file. If the
conf/logging.properties file does not exist, I believe the default
logging.properties will be used (which is what happens now.)
> Embeddable class to call solr directly
> --
>
> Key: SOLR-212
> URL: https://issues.apache.org/jira/browse/SOLR-212
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch
>
>
> For some embedded applications, it is useful to call solr without running an
> HTTP server. This class mimics the behavior you would get if you sent the
> request through an HTTP connection. It is designed to work nicely (ie
> simple) with JNI
> the main function is:
> public class DirectSolrConnection
> {
> String request( String pathAndParams, String body ) throws Exception
> {
> ...
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-212) Embeddable class to call solr directly
[
https://issues.apache.org/jira/browse/SOLR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492518
]
Brian Whitman commented on SOLR-212:
Much love from user land on this one. I just successfully put solr in a C app
without any webserver running using JNI.
After I clean up my JNI calling code I can post an example app here to show how
it's done on the client side if anyone is interested?
> Embeddable class to call solr directly
> --
>
> Key: SOLR-212
> URL: https://issues.apache.org/jira/browse/SOLR-212
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-212-DirectSolrConnection.patch,
> SOLR-212-DirectSolrConnection.patch, SOLR-212-DirectSolrConnection.patch
>
>
> For some embedded applications, it is useful to call solr without running an
> HTTP server. This class mimics the behavior you would get if you sent the
> request through an HTTP connection. It is designed to work nicely (ie
> simple) with JNI
> the main function is:
> public class DirectSolrConnection
> {
> String request( String pathAndParams, String body ) throws Exception
> {
> ...
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-208) RSS feed XSL example
RSS feed XSL example Key: SOLR-208 URL: https://issues.apache.org/jira/browse/SOLR-208 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.2 Reporter: Brian Whitman Priority: Trivial Attachments: rss.xsl A quick .xsl file for transforming solr queries into RSS feeds. To get the date and time in properly you'll need an XSL 2.0 processor, as in http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the example solr distribution in the nightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-208) RSS feed XSL example
[ https://issues.apache.org/jira/browse/SOLR-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-208: --- Attachment: rss.xsl Attaching the rss.xsl file -- just put this in solr/conf/xslt/ and then try http://localhost:8983/solr/select?q=ipod&wt=xslt&tr=rss.xsl > RSS feed XSL example > > > Key: SOLR-208 > URL: https://issues.apache.org/jira/browse/SOLR-208 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.2 >Reporter: Brian Whitman >Priority: Trivial > Attachments: rss.xsl > > > A quick .xsl file for transforming solr queries into RSS feeds. To get the > date and time in properly you'll need an XSL 2.0 processor, as in > http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the > example solr distribution in the nightly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480116 ] Brian Whitman commented on SOLR-69: --- Yes, paging and size would be helpful in the MLT section. mlt.start and mlt.rows would be great. > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479887 ] Brian Whitman commented on SOLR-69: --- Is there a way to get this patch to listen to start & rows on the moreLikeThis result section? > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-149) Make solr more embeddable
[ https://issues.apache.org/jira/browse/SOLR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472056 ] Brian Whitman commented on SOLR-149: Using this in a Java / Cocoa bridge, it's gorgeous. Thanks Ryan. > Make solr more embeddable > - > > Key: SOLR-149 > URL: https://issues.apache.org/jira/browse/SOLR-149 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-149-embeddable.patch > > > With a few simple changes, solr can be an easily embedded in a custom jetty > app. > With this patch, one can run solr from the jar file using: > server = new Server( port ); > > // Initalize home (without JNDI) > Config.setInstanceDir(home); > > // Initalize the servlets > Context root = new Context( server, "/", Context.SESSIONS ); > root.addServlet( SolrServlet.class, "/select" ); > root.addServlet( SolrUpdateServlet.class, "/update" ); > root.addFilter( SolrDispatchFilter.class, "*", Handler.REQUEST ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469229 ] Brian Whitman commented on SOLR-69: --- There's a typo in the latest uploaded patch -- - map.put(MIN_DOC_FREQ, String.valueOf(MoreLikeThis.DEFALT_MIN_DOC_FREQ)); + map.put(MIN_DOC_FREQ, String.valueOf(MoreLikeThis.DEFAULT_MIN_DOC_FREQ)); > PATCH:MoreLikeThis support > -- > > Key: SOLR-69 > URL: https://issues.apache.org/jira/browse/SOLR-69 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, > SOLR-69.patch > > > Here's a patch that implements simple support of Lucene's MoreLikeThis class. > The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be > more appropriate ;-) Erik Hatcher's example mentioned in > http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html > To use it, add at least the following parameters to a standard or dismax > query: > mlt=true > mlt.fl=list,of,fields,which,define,similarity > See the MoreLikeThisHelper source code for more parameters. > Here are two URLs that work with the example config, after loading all > documents found in exampledocs in the index (just to show that it seems to > work - of course you need a larger corpus to make it interesting): > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score > Results are added to the output like this: > > ... > > > > 1.5293242 > SOLR1000 > > > > > 1.5293242 > UTF8TEST > > > > I haven't tested this extensively yet, will do in the next few days. But > comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
