[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] 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-tabpanelfocusedCommentId=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 LinkedHashMapString,Object();
[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 LinkedHashMapString,Object();
[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-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-tabpanelfocusedCommentId=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 LinkedHashMapString,Object();
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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) : spanI/span spanLove/span spanYou/span But spanI've/span spanChosen/span spanDarkness/span : should really be Lights (Live) : spanI Love You But I've Chosen Darkness/span : 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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:webhl.simple.pre=spanhl.simple.post=/spanhighlight=truehl.fl=content Returns docs like: spana/span spanb/span spanc/span spanweb/span 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] 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:webhl.simple.pre=spanhl.simple.post=/spanhighlight=truehl.fl=content Returns docs like: spana/span spanb/span spanc/span spanweb/span 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:webhl.simple.pre=spanhl.simple.post=/spanhighlight=truehl.fl=content Returns docs like: spana/span spanb/span spanc/span spanweb/span 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] 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] 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] 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-tabpanelfocusedCommentId=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; imaxResults; i=i+blockSize) {
// Sets rows of this query to the most results that could ever come back
- the blockSize * the number of shards
q.setRows(blockSize * getNumberOfHosts());
// Don't set a start on the main query
q.setStart(0);
// But do set start and rows on the individual shards.
q.set(shards.start, String.valueOf(i));
q.set(shards.rows, String.valueOf(blockSize));
// Perform the query.
QueryResponse sub = query(q);
// For each returned document (up to blockSize*numberOfHosts() of them),
append them to the main result
for(SolrDocument s : sub.getResults()) {
allResults.add(s);
// Break if we've reached our requested limit
if(allResults.size() 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] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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%20descfl=indexedrows=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] 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-tabpanelfocusedCommentId=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%20descfl=indexedrows=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%20descfl=indexedrows=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)
[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-tabpanelfocusedCommentId=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] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611368#action_12611368
]
Brian Whitman commented on SOLR-303:
Anyone notice something like this:
http://localhost:8983/solr/select?shards={4 shards}q=*:*start=5000rows=1000
Seems to request rows=6000 from all the shards? (likewise,
start=1rows=1000 sends rows=11000 to all the shards?)
The shards all say:
INFO: webapp=/solr path=/select
params={fl=id,scorestart=0q=*:*isShard=truewt=javabinfsv=truerows=6000version=2.2}
hits=6000 status=0 QTime=175
And the host I called select on says:
INFO: webapp=/solr path=/search params={start=5000q=*:*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] 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-tabpanelfocusedCommentId=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/solrdebugQuery=trueq=i_tag:894rows=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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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/solrdebugQuery=trueq=i_tag:894rows=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-tabpanelfocusedCommentId=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/solrq=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-tabpanelfocusedCommentId=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=100q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22fq=type:htmlhl=truehl.fl=contenthl.fragsize=500hl.snippets=5hl.simple.pre=%3Cspan%3Ehl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : spanI/span spanLove/span spanYou/span But spanI've/span spanChosen/span spanDarkness/span : But also returns unrelated snips from the same page: Black Francis Shop spanI/span Think spanI/span spanLove/span spanYou/span 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: --- 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%22hl=onhl.fl=featureshl.fragsize=20hl.snippets=10 Expected results: the only highlight snip results returned should be emax bx cx/em 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=100q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22fq=type:htmlhl=truehl.fl=contenthl.fragsize=500hl.snippets=5hl.simple.pre=%3Cspan%3Ehl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : spanI/span spanLove/span spanYou/span But spanI've/span spanChosen/span spanDarkness/span : But also returns unrelated snips from the same page: Black Francis Shop spanI/span Think spanI/span spanLove/span spanYou/span A correct highlighter should only return Lights (Live) : spanI Love You But I've Chosen Darkness/span 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 spanA Long String/span 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] 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=100q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22fq=type:htmlhl=truehl.fl=contenthl.fragsize=500hl.snippets=5hl.simple.pre=%3Cspan%3Ehl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : spanI/span spanLove/span spanYou/span But spanI've/span spanChosen/span spanDarkness/span : But also returns unrelated snips from the same page: Black Francis Shop spanI/span Think spanI/span spanLove/span spanYou/span A correct highlighter should only return Lights (Live) : spanI Love You But I've Chosen Darkness/span 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 spanA Long String/span 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=100q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22fq=type:htmlhl=truehl.fl=contenthl.fragsize=500hl.snippets=5hl.simple.pre=%3Cspan%3Ehl.simple.post=%3C/span%3E The highlight returns a snippet that does have the name altogether: Lights (Live) : spanI/span spanLove/span spanYou/span But spanI've/span spanChosen/span spanDarkness/span : But also returns unrelated snips from the same page: Black Francis Shop spanI/span Think spanI/span spanLove/span spanYou/span A correct highlighter should only return Lights (Live) : spanI Love You But I've Chosen Darkness/span 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.
Re: debugging slowness
On Dec 19, 2007, at 9:34 AM, Yonik Seeley wrote: On Dec 19, 2007 9:23 AM, Brian Whitman [EMAIL PROTECTED] wrote: It's pretty easy to parse access logs or solr query logs and find the offenders (I don't have any parsing code at my fingertips though...) Do these periods of slowness tend to happen right after a commit? Do the slow queries have anything in common? All queries become slow, so looking at the access logs don't help us much. After some amount of time (variable, but measured in days) Solr just becomes slow for us, every query takes 20-30s. I was looking for more code-level sampling/logging (to see if I could fix it.) Or at least see if it's a resin thing vs. a solr thing. The index in question has a 15m autocommit and gets about 1-3 new documents/second.
Re: DirectSolrConnection, write.lock and Too Many Open Files
On Sep 10, 2007, at 1:56 PM, Mike Klaas wrote: I'm a little worried about Solr getting a bad rap for being buggy or not well-documented due to people trying to use it embeddedly. It seems that we need to do one of two things: 1. Someone lead the effort to clean up and organize the situation, develop and test the relevant api, and document it to the standards of the rest of Solr. 2. Remove references to embedding Solr (including out-of-date wiki pages) if we do not have a maintainer for this functionality. We have a desktop app in alpha now that uses Solr as its data store backend via DirectSolrConnection. It makes a lot of sense in our app especially as the web-app side of the app is also built on Solr. We have a lot of people banging on the code and other than the thread lock issue Adrian and I mentioned, there's been absolutely no problem -- it's fast, stable, relatively low overhead, x-platform and does exactly what we need. I would volunteer to be the DSC maintainer as I probably use it the most, but unfortunately I am not a competent java dev (Ryan can attest to this.) I will volunteer to clean up the end user docs, specifically I owe the wiki a non-objc version of the JNI code.
Re: Multiple Indices with Solr
On Aug 19, 2007, at 3:16 PM, Jay Booth wrote: Hey guys, great job with solr. I've been using a similar server- wrapped-around-lucene setup for a few years now and am migrating over to solr. My big issue is that I need to maintain 4 different search indices with different schema, only moving one over for now but I like to think ahead, so here are my options: Make sure you read and/or try out https://issues.apache.org/jira/ browse/SOLR-215
[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] 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] 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.
Re: SOLR-69?
On Jun 1, 2007, at 11:39 PM, Ryan McKinley wrote: How do you all feel about commiting SOLR-69? It does not affect anyone who does not ask to use it... I would love it to be committed but are you also going to put lucene- queries jar in as well? Or can we just copy over that MLT class from Lucene into solr? I think MLT should eventually be a Solr first-class thing, like faceting, assuming we can work out some of the performance issues. I don't think it should rely on a contrib jar in Lucene that hasn't been updated in some time.
Re: svn commit: r541391 - in /lucene/solr/trunk: CHANGES.txt example/solr/conf/xslt/example_atom.xsl example/solr/conf/xslt/example_rss.xsl
Some versions of RSS are quite incompatible, so we MUST say what version we are implementing. RSS 1.0 is completely different from the 0.9 series and 2.0. Atom doesn't have a version number, but RFC 4287 Atom is informally called 1.0. The rss_example is supposed to be RSS 2.0. The atom_example validated on feedvalidator.org as Atom 1.0, I assume that's the RFC 4287.
[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] 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-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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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_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:100mlt.fl=contentfl=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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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_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:BOOK01mlt.fl=contentsfq=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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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] 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-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('result status=0'):
When detecting if /update didn't like something. With the latest solr trunk,
that doesn't come back anymore. It looks like:
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint
name=QTime40/int/lst
/response
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.
Re: Custom fragmenter
On May 2, 2007, at 3:21 PM, Mike Klaas wrote: On 5/2/07, Brian Whitman [EMAIL PROTECTED] wrote: Would love to set a custom fragmenter in Solr for highlighting. But I don't see a way to change the fragmenter on the fly. Should this be a solrconfig/schema setting? It would be nice to able to register custom formatters and subsequently use them in queries: Just to make sure, I was talking about fragmenters, not formatters -- but having custom formatters in solrconfig would be good too!
[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.
Custom fragmenter
Would love to set a custom fragmenter in Solr for highlighting. But I don't see a way to change the fragmenter on the fly. Should this be a solrconfig/schema setting?
[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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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] 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-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_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] 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] 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=ipodwt=xslttr=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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst 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.
