[jira] Commented: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833440#action_12833440 ] David Bowen commented on SOLR-1143: --- I've found this patch very useful. I recommend extending it to check for instanceof IOException rather than just java.net.ConnectException. This is useful in order to catch org.apache.commons.httpclient.ConnectTimeoutException and java.net.SocketTimeoutException. Return partial results when a connection to a shard is refused -- Key: SOLR-1143 URL: https://issues.apache.org/jira/browse/SOLR-1143 Project: Solr Issue Type: Improvement Components: search Reporter: Nicolas Dessaigne Assignee: Grant Ingersoll Fix For: 1.5 Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch If any shard is down in a distributed search, a ConnectException it thrown. Here's a little patch that change this behaviour: if we can't connect to a shard (ConnectException), we get partial results from the active shards. As for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we set the parameter partialResults at true. This patch also adresses a problem expressed in the mailing list about a year ago (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) We have a use case that needs this behaviour and we would like to know your thougths about such a behaviour? Should it be the default behaviour for distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1579) CLONE -stats.jsp XML escaping
[ https://issues.apache.org/jira/browse/SOLR-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bowen updated SOLR-1579: -- Attachment: SOLR-1579.patch This is a trivial fix, but I'm supplying a patch in the hope of raising the priority. CLONE -stats.jsp XML escaping - Key: SOLR-1579 URL: https://issues.apache.org/jira/browse/SOLR-1579 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.4 Reporter: David Bowen Assignee: Erik Hatcher Fix For: 1.5 Attachments: SOLR-1579.patch Original Estimate: 1h Remaining Estimate: 1h The fix to SOLR-1008 was wrong. It used chardata escaping for a value that is an attribute value. I.e. instead of XML.escapeCharData it should call XML.escapeAttributeValue. Otherwise, any query used as a key in the filter cache whose printed representation contains a double-quote character causes invalid XML to be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1658) Negative query weirdness
Negative query weirdness Key: SOLR-1658 URL: https://issues.apache.org/jira/browse/SOLR-1658 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: David Bowen In the standard Solr example, the queries # adapter AND NOT power # adapter AND (NOT power) are different. The second will never return any results. I find this surprising. I think the second query should be the same as the first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1579) CLONE -stats.jsp XML escaping
CLONE -stats.jsp XML escaping - Key: SOLR-1579 URL: https://issues.apache.org/jira/browse/SOLR-1579 Project: Solr Issue Type: Bug Components: web gui Reporter: David Bowen Assignee: Erik Hatcher Fix For: 1.4 stats.jsp gave this error: Line Number 1327, Column 48:stat name=item_attrFacet_Size__Shape stat names are not XML escaped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1579) CLONE -stats.jsp XML escaping
[ https://issues.apache.org/jira/browse/SOLR-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bowen updated SOLR-1579: -- Description: The fix to SOLR-1008 was wrong. It used chardata escaping for a value that is an attribute value. I.e. instead of XML.escapeCharData it should call XML.escapeAttributeValue. Otherwise, any query used as a key in the filter cache whose printed representation contains a double-quote character causes invalid XML to be generated. was: stats.jsp gave this error: Line Number 1327, Column 48:stat name=item_attrFacet_Size__Shape stat names are not XML escaped. Affects Version/s: 1.4 CLONE -stats.jsp XML escaping - Key: SOLR-1579 URL: https://issues.apache.org/jira/browse/SOLR-1579 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.4 Reporter: David Bowen Assignee: Erik Hatcher Fix For: 1.4 Original Estimate: 1h Remaining Estimate: 1h The fix to SOLR-1008 was wrong. It used chardata escaping for a value that is an attribute value. I.e. instead of XML.escapeCharData it should call XML.escapeAttributeValue. Otherwise, any query used as a key in the filter cache whose printed representation contains a double-quote character causes invalid XML to be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1283) Mark Invalid error on indexing
[
https://issues.apache.org/jira/browse/SOLR-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770586#action_12770586
]
David Bowen commented on SOLR-1283:
---
It seems to me that the code should bail out and just assume that a did not
begin an HTML tag if it still isn't sure after reading the DEFAULT_READ_AHEAD
(8,192) characters. It looks like the code was intended to do that (see the
checks against safeReadAheadLimit) but must be missing some case.
Mark Invalid error on indexing
--
Key: SOLR-1283
URL: https://issues.apache.org/jira/browse/SOLR-1283
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Environment: Ubuntu 8.04, Sun Java 6
Reporter: solrize
When indexing large (1 megabyte) documents I get a lot of exceptions with
stack traces like the below. It happens both in the Solr 1.3 release and in
the July 9 1.4 nightly. I believe this to NOT be the same issue as SOLR-42.
I found some further discussion on solr-user:
http://www.nabble.com/IOException:-Mark-invalid-while-analyzing-HTML-td17052153.html
In that discussion, Grant asked the original poster to open a Jira issue, but
I didn't see one so I'm opening one; please feel free to merge or close if
it's redundant.
My stack trace follows.
Jul 15, 2009 8:36:42 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/update params={} status=500 QTime=3
Jul 15, 2009 8:36:42 AM org.apache.solr.common.SolrException log
SEVERE: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:485)
at
org.apache.solr.analysis.HTMLStripReader.restoreState(HTMLStripReader.java:171)
at
org.apache.solr.analysis.HTMLStripReader.read(HTMLStripReader.java:728)
at
org.apache.solr.analysis.HTMLStripReader.read(HTMLStripReader.java:742)
at java.io.Reader.read(Reader.java:123)
at
org.apache.lucene.analysis.CharTokenizer.next(CharTokenizer.java:108)
at org.apache.lucene.analysis.StopFilter.next(StopFilter.java:178)
at
org.apache.lucene.analysis.standard.StandardFilter.next(StandardFilter.java:84)
at
org.apache.lucene.analysis.LowerCaseFilter.next(LowerCaseFilter.java:53)
at
org.apache.solr.analysis.WordDelimiterFilter.next(WordDelimiterFilter.java:347)
at
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:159)
at
org.apache.lucene.index.DocFieldConsumersPerField.processFields(DocFieldConsumersPerField.java:36)
at
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:234)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:765)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:748)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2512)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2484)
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:240)
at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1292)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
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
[jira] Updated: (SOLR-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
[
https://issues.apache.org/jira/browse/SOLR-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bowen updated SOLR-1407:
--
Description:
SpellingQueryConverter was extended to cover the full UTF-8 range instead of
handling US-ASCII only, but in the process it was broken for field names that
contain underscores or digits.
was:
Solr - User - SpellCheckComponent: queryAnalyzerFieldType
http://www.nabble.com/SpellCheckComponent%3A-queryAnalyzerFieldType-td23870668.html
In the above thread, it was suggested to extend the SpellingQueryConverter to
cover the full UTF-8 range instead of handling US-ASCII only. This might be as
simple as changing the regular expression used to tokenize the input string to
accept a sequence of one or more Unicode letters ( \p{L}+ ) instead of a
sequence of one or more word characters ( \w+ ).
See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for
Java regular expression reference.
SpellingQueryConverter now disallows underscores and digits in field names
(but allows all UTF-8 letters)
-
Key: SOLR-1407
URL: https://issues.apache.org/jira/browse/SOLR-1407
Project: Solr
Issue Type: Improvement
Components: spellchecker
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.4
SpellingQueryConverter was extended to cover the full UTF-8 range instead of
handling US-ASCII only, but in the process it was broken for field names that
contain underscores or digits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
SpellingQueryConverter now disallows underscores and digits in field names (but
allows all UTF-8 letters)
-
Key: SOLR-1407
URL: https://issues.apache.org/jira/browse/SOLR-1407
Project: Solr
Issue Type: Improvement
Components: spellchecker
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.4
Solr - User - SpellCheckComponent: queryAnalyzerFieldType
http://www.nabble.com/SpellCheckComponent%3A-queryAnalyzerFieldType-td23870668.html
In the above thread, it was suggested to extend the SpellingQueryConverter to
cover the full UTF-8 range instead of handling US-ASCII only. This might be as
simple as changing the regular expression used to tokenize the input string to
accept a sequence of one or more Unicode letters ( \p{L}+ ) instead of a
sequence of one or more word characters ( \w+ ).
See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for
Java regular expression reference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1204) Enhance SpellingQueryConverter to handle UTF-8 instead of ASCII only
[
https://issues.apache.org/jira/browse/SOLR-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751315#action_12751315
]
David Bowen commented on SOLR-1204:
---
Since this ticket is marked resolved, I filed SOLR-1407 to point out some
closely related problems.
Enhance SpellingQueryConverter to handle UTF-8 instead of ASCII only
Key: SOLR-1204
URL: https://issues.apache.org/jira/browse/SOLR-1204
Project: Solr
Issue Type: Improvement
Components: spellchecker
Affects Versions: 1.3
Reporter: Michael Ludwig
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.4
Attachments: SpellingQueryConverter.java.diff,
SpellingQueryConverter.java.diff
Solr - User - SpellCheckComponent: queryAnalyzerFieldType
http://www.nabble.com/SpellCheckComponent%3A-queryAnalyzerFieldType-td23870668.html
In the above thread, it was suggested to extend the SpellingQueryConverter to
cover the full UTF-8 range instead of handling US-ASCII only. This might be
as simple as changing the regular expression used to tokenize the input
string to accept a sequence of one or more Unicode letters ( \p{L}+ ) instead
of a sequence of one or more word characters ( \w+ ).
See http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html for
Java regular expression reference.
--
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-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
[
https://issues.apache.org/jira/browse/SOLR-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751317#action_12751317
]
David Bowen edited comment on SOLR-1407 at 9/3/09 10:52 PM:
This is perhaps a separate issue, but I think this class should skip search
terms containing wildcards, since it doesn't make sense to make spelling
suggestions for a term containing a wildcard. Probably it should also skip
terms with a fuzzy-match suffix.
Also, it should skip NOT as well as AND and OR.
was (Author: dbowen):
This is perhaps a separate issue, but I think this class should skip search
terms containing wildcards, since it doesn't make sense to make spelling
suggestions for a term containing a wildcard. Probably it should also skip
terms with a fuzzy-match suffix.
Also, it should skip NOT as well as AND and OR.
Something like this:
pre
protected Pattern QUERY_REGEX =
Pattern.compile((?:(?!(\\w+:|\\d+)))(\\p{L}|[?*~])+);
protected Pattern WILD_OR_FUZZY = Pattern.compile([?*~]);
/**
* Converts the original query string to a collection of Lucene Tokens.
* @param original the original query string
* @return a Collection of Lucene Tokens
*/
@Override
public CollectionToken convert(String original) {
if (original == null) { // this can happen with q.alt = and no query
return Collections.emptyList();
}
CollectionToken result = new ArrayListToken();
//TODO: Extract the words using a simple regex, but not query stuff, and
then analyze them to produce the token stream
Matcher matcher = QUERY_REGEX.matcher(original);
TokenStream stream;
while (matcher.find()) {
String word = matcher.group(0);
if (!word.equals(AND) !word.equals(OR) !word.equals(NOT)
!WILD_OR_FUZZY.matcher(word).find())
{
try {
stream = analyzer.reusableTokenStream(, new StringReader(word));
Token token;
while ((token = stream.next()) != null) {
token.setStartOffset(matcher.start());
token.setEndOffset(matcher.end());
result.add(token);
}
} catch (IOException e) {
}
}
}
return result;
}
/pre
SpellingQueryConverter now disallows underscores and digits in field names
(but allows all UTF-8 letters)
-
Key: SOLR-1407
URL: https://issues.apache.org/jira/browse/SOLR-1407
Project: Solr
Issue Type: Improvement
Components: spellchecker
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.4
SpellingQueryConverter was extended to cover the full UTF-8 range instead of
handling US-ASCII only, but in the process it was broken for field names that
contain underscores or digits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
[
https://issues.apache.org/jira/browse/SOLR-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751317#action_12751317
]
David Bowen commented on SOLR-1407:
---
This is perhaps a separate issue, but I think this class should skip search
terms containing wildcards, since it doesn't make sense to make spelling
suggestions for a term containing a wildcard. Probably it should also skip
terms with a fuzzy-match suffix.
Also, it should skip NOT as well as AND and OR.
Something like this:
pre
protected Pattern QUERY_REGEX =
Pattern.compile((?:(?!(\\w+:|\\d+)))(\\p{L}|[?*~])+);
protected Pattern WILD_OR_FUZZY = Pattern.compile([?*~]);
/**
* Converts the original query string to a collection of Lucene Tokens.
* @param original the original query string
* @return a Collection of Lucene Tokens
*/
@Override
public CollectionToken convert(String original) {
if (original == null) { // this can happen with q.alt = and no query
return Collections.emptyList();
}
CollectionToken result = new ArrayListToken();
//TODO: Extract the words using a simple regex, but not query stuff, and
then analyze them to produce the token stream
Matcher matcher = QUERY_REGEX.matcher(original);
TokenStream stream;
while (matcher.find()) {
String word = matcher.group(0);
if (!word.equals(AND) !word.equals(OR) !word.equals(NOT)
!WILD_OR_FUZZY.matcher(word).find())
{
try {
stream = analyzer.reusableTokenStream(, new StringReader(word));
Token token;
while ((token = stream.next()) != null) {
token.setStartOffset(matcher.start());
token.setEndOffset(matcher.end());
result.add(token);
}
} catch (IOException e) {
}
}
}
return result;
}
/pre
SpellingQueryConverter now disallows underscores and digits in field names
(but allows all UTF-8 letters)
-
Key: SOLR-1407
URL: https://issues.apache.org/jira/browse/SOLR-1407
Project: Solr
Issue Type: Improvement
Components: spellchecker
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.4
SpellingQueryConverter was extended to cover the full UTF-8 range instead of
handling US-ASCII only, but in the process it was broken for field names that
contain underscores or digits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
[ https://issues.apache.org/jira/browse/SOLR-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bowen updated SOLR-1407: -- Attachment: SpellingQueryConverter.java SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters) - Key: SOLR-1407 URL: https://issues.apache.org/jira/browse/SOLR-1407 Project: Solr Issue Type: Improvement Components: spellchecker Affects Versions: 1.3 Reporter: David Bowen Assignee: Shalin Shekhar Mangar Priority: Trivial Fix For: 1.4 Attachments: SpellingQueryConverter.java SpellingQueryConverter was extended to cover the full UTF-8 range instead of handling US-ASCII only, but in the process it was broken for field names that contain underscores or digits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12736145#action_12736145 ] David Bowen commented on SOLR-1299: --- Many thanks Shalin. Your fix works for us. In distributed search cannot search on any schema field in ascending order (descending is OK) - Key: SOLR-1299 URL: https://issues.apache.org/jira/browse/SOLR-1299 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: David Bowen Fix For: 1.4 Attachments: SOLR-1299.patch Using the example with some of the exampledocs posted, the url: http://localhost:8983/solr/select/?q=*:*sort=timestamp+descfsv=true works correctly, but change desc to asc and you get: HTTP ERROR: 500 null java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) 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) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1299) In distributed search cannot search on a date field in ascending order (descending is OK)
In distributed search cannot search on a date field in ascending order (descending is OK) - Key: SOLR-1299 URL: https://issues.apache.org/jira/browse/SOLR-1299 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: David Bowen Using the example with some of the exampledocs posted, the url: http://localhost:8983/solr/select/?q=*:*sort=timestamp+descfsv=true works correctly, but change desc to asc and you get: HTTP ERROR: 500 null java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) 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) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-925) Highlighter doesn't work on a field which is multiValued=true and termOffsets=true
[
https://issues.apache.org/jira/browse/SOLR-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659178#action_12659178
]
David Bowen commented on SOLR-925:
--
That's strange. I get this:
{noformat}
lst name=highlighting
lst name=Test for Highlighting StringIndexOutOfBoundsExcdption
arr name=features
strDescription of the emfeatures/em, mentioning various things/str
strFeatures also is muemltivalue/emd/str
/arr
/lst
/lst
{noformat}
Highlighter doesn't work on a field which is multiValued=true and
termOffsets=true
--
Key: SOLR-925
URL: https://issues.apache.org/jira/browse/SOLR-925
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: SOLR-925.patch
This seems to be introduced at r674677.
{panel}
java.lang.StringIndexOutOfBoundsException: String index out of range: 15
at java.lang.String.substring(Unknown Source)
at
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
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)
{panel}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-925) Highlighter doesn't work on a field which is multiValued=true and termOffsets=true
[
https://issues.apache.org/jira/browse/SOLR-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659179#action_12659179
]
David Bowen commented on SOLR-925:
--
Ack! Sorry Koji, my mistake. I was inadvertently using a patched Lucene
highlighter class which apparently causes this problem.
+1 on committing this patch.
Highlighter doesn't work on a field which is multiValued=true and
termOffsets=true
--
Key: SOLR-925
URL: https://issues.apache.org/jira/browse/SOLR-925
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: SOLR-925.patch
This seems to be introduced at r674677.
{panel}
java.lang.StringIndexOutOfBoundsException: String index out of range: 15
at java.lang.String.substring(Unknown Source)
at
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
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)
{panel}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-937) Highlighting problem related to stemming
Highlighting problem related to stemming Key: SOLR-937 URL: https://issues.apache.org/jira/browse/SOLR-937 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.3 Reporter: David Bowen Using the example data (as in ant run-example) from the latest dev version, add the words electronics and connector to the features field of the first doc in ipod_other.xml. Now the following query: http://localhost:8983/solr/select/?q=electronicshl=truehl.fl=features+cat will show electronics highlighted in the features field but not in the cat field. If you search instead for connector, it is highlighted in both. This seems like a bug to me. A possible but not entirely satisfactory work-around would be to have the cat field copied into another field which is stemmed, and use that other field for highlighting (assuming the search is on the default search field, and not on cat). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-925) Highlighter doesn't work on a field which is multiValued=true and termOffsets=true
[
https://issues.apache.org/jira/browse/SOLR-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658743#action_12658743
]
David Bowen commented on SOLR-925:
--
-1 on this patch. If you try this example (using the example as in ant
run-example):
adddoc
field name=idTest for Highlighting StringIndexOutOfBoundsExcdption/field
field name=nameSome Name/field
field name=manuAcme, Inc./field
field name=featuresDescription of the features, mentioning various
things/field
field name=featuresFeatures also is multivalued/field
field name=popularity6/field
field name=inStocktrue/field
/doc/add
then this url
http://localhost:8983/solr/select/?q=featureshl=truehl.snippets=2hl.fl=featureshl.fragsize=0
shows correct highlighting in the first snippet, but highlighting is shifted
right about 19 characters in the second.
Highlighter doesn't work on a field which is multiValued=true and
termOffsets=true
--
Key: SOLR-925
URL: https://issues.apache.org/jira/browse/SOLR-925
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: SOLR-925.patch
This seems to be introduced at r674677.
{panel}
java.lang.StringIndexOutOfBoundsException: String index out of range: 15
at java.lang.String.substring(Unknown Source)
at
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
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)
{panel}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-802) Trivial bug which could cause null pointer exception
Trivial bug which could cause null pointer exception Key: SOLR-802 URL: https://issues.apache.org/jira/browse/SOLR-802 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: David Bowen Priority: Minor In FacetComponent there's an which should be a . Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-802) Trivial bug which could cause null pointer exception
[ https://issues.apache.org/jira/browse/SOLR-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bowen updated SOLR-802: - Attachment: patch Here's the one-character patch. Trivial bug which could cause null pointer exception Key: SOLR-802 URL: https://issues.apache.org/jira/browse/SOLR-802 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: David Bowen Priority: Minor Attachments: patch In FacetComponent there's an which should be a . Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
