[jira] Updated: (SOLR-1488) autoCommit when idle
[ https://issues.apache.org/jira/browse/SOLR-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1488: - Attachment: SOLR-1488.patch This patch adds autoCommit after idle support. If maxTime and idleTime are both defined in solrconfig.xml, then maxTime takes precedence. > autoCommit when idle > > > Key: SOLR-1488 > URL: https://issues.apache.org/jira/browse/SOLR-1488 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Matt Weber >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1488.patch > > > Enable autoCommit to execute after a given amount of idle time (no documents > submitted). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1488) autoCommit when idle
autoCommit when idle Key: SOLR-1488 URL: https://issues.apache.org/jira/browse/SOLR-1488 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Priority: Minor Fix For: 1.4 Enable autoCommit to execute after a given amount of idle time (no documents submitted). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761763#action_12761763 ] Uwe Schindler commented on SOLR-1221: - I would also stay with 2.9 in Solr. Just mark the removal of the wrapper as a TODO item after the next lucene update. > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761761#action_12761761 ] Mark Miller commented on SOLR-1221: --- bq. But we fix the highlighter bug in lucene trunk, too? Yup, def. The only reason we are trying to sidestep here is to avoid having to update the jar in Solr. Its just a hassle. What do we call it and how do we track it? Back against the wall, I think it makes sense, but not if we can sidestep and go pure 2.9 release. I'll commit a fix in Lucene over the weekend - super easy fix there anyway. > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761759#action_12761759 ] Uwe Schindler commented on SOLR-1221: - I have no preference... But we fix the highlighter bug in lucene trunk, too? > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761757#action_12761757 ] Mark Miller commented on SOLR-1221: --- On first blush, I've got to think the wrapper is better. We don't lose the few terms -> faster booleanquery that way, and I'm not sure I see any advantage to using CSQ. So its not a huge weight towards the wrapper, but we now have it, and it does weigh that way it would seem to me ... Uwe? > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761749#action_12761749 ] Yonik Seeley commented on SOLR-1221: bq. Instead of using a NRQ, wrap a NRF with ConstantScoreQuery Yep, that would work too. Your call Mark ;-) > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1487) Add expungeDelete to SolrJ's SolrServer.commit(..)
Add expungeDelete to SolrJ's SolrServer.commit(..) --- Key: SOLR-1487 URL: https://issues.apache.org/jira/browse/SOLR-1487 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Environment: N/A Reporter: Jibo John Add expungeDelete to SolrJ's SolrServer.commit(..). Currently, this can be done only through updatehandler ( ( curl update -F stream.body=' ' )) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761725#action_12761725 ] Yonik Seeley commented on SOLR-1478: A Lucene field name can be anything... so '#' could also be a collision. If we wish to reserve certain names going forward, I'd vote for reserving ids with an underscore on either side. But really, the whole collision thing is overblown... this is a single name that people will not have used before. On a practical level, I don't believe it's an issue. We will need another one too - as a container for document metadata. I've suggested _meta_ for that in SOLR-705. We aren't adding these all the time... there was exactly one before this.. "score". No future document level metadata will collide since they will be contained in whatever _meta_ ends up being. Further advantages to __id__ (single underscores surrounding the id): - consistent with magic fieldnames __query__ and __val__ for nested queries in the query parser, and I could see supporting __id__:1 in the future - people *may* want to return the actual ids for documents... wherever that info goes (separate return vector like sort_field_values for distributed search or __meta__) it will be nicer for clients if the label for it is actually an identifier and not '#' > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
examining/modifying qstr in QParserPlugin
sorry if this is a very simple question, but I am stuck (and online searches
for this info havent been fruitful).
Lets say that, in certain circumstances, I want to change the field names
and/or field query values being passed to SOLR.
For example, lets say my unmodified query is
"http://localhost:8994/solr/select?q=xxx:[* TO 3] AND yyy:[3 TO
*]&defType=myQParser" and (JUST for the sake of argument) lets say I want to
rewrite it as "http://localhost:8994/solr/select?q=aaa:[1 TO 2] AND bbb:[3
TO 10]&defType=myQParser".
I think I can do it by extending QParserPlugin, and overriding the
createParser method (see my code snippet below). The qstr parameter contains
the parts I want to examine and/or modify.
now to my questions:
1. is that the correct location to do this?
2. is there an existing method for parsing out the fields and their
parameters? i.e. to break a qstr of "xxx:[* TO 3] AND yyy:[3 TO *]" into an
array something like x[0][0] = "xxx", x[0][1]="1 TO 3", x[1][0] = "xxx",
x[1][1]="3 TO *". Or possibly even finer than that. I could write it
myself but its nicer not to have to.=^D
thanks in advance for any help.
package com.topproducer.rentals.solr.search;
import org.apache.lucene.queryParser.ParseException;
import org.apache.lucene.search.Query;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.search.QParser;
import org.apache.solr.search.QParserPlugin;
public class myQParserPlugin extends QParserPlugin {
@Override
public QParser createParser(String qstr, SolrParams localParams,
SolrParams
params, SolrQueryRequest req)
{
return new QParser(qstr, localParams, params, req) {
QParser baseParser;
public Query parse() throws ParseException {
StringBuilder queryBuilder = new StringBuilder();
// extract and/or view and/or change qstr content here
// ..
// is there an existing function/method to parse qstr
into its component
parts?
// i.e. to break "?q=xxx:[1 TO 3] AND yyy:[3 TO *]"
into something like:
// x[0][0] = "xxx", x[0][1]="1 TO 3"
// x[1][0] = "xxx", x[1][1]="3 TO *"
// after modifying qstr, store it into queryBuilder here
queryBuild.append(new_qstr);
// prepare queryBuilder for any additional solr handling
baseParser = subQuery(queryBuilder.toString(), null);
Query q = baseParser.parse();
return q;
}
public String[] getDefaultHighlightFields() {
return baseParser.getDefaultHighlightFields();
}
public Query getHighlightQuery() throws ParseException {
return baseParser.getHighlightQuery();
}
public void addDebugInfo(NamedList debugInfo) {
baseParser.addDebugInfo(debugInfo);
}
};
}
@Override
public void init(NamedList arg0) {
// TODO Auto-generated method stub
}
}
--
View this message in context:
http://www.nabble.com/examining-modifying-qstr-in-QParserPlugin-tp25722065p25722065.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-1478) Enable sort by docid
[
https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761710#action_12761710
]
Steven Rowe commented on SOLR-1478:
---
Another thought: the XML specification reserves names matching regex
{{/^xml/i}} to itself for future use (see
http://www.w3.org/TR/xml/#sec-common-syn). Maybe Solr should do the same?
That way, this discussion wouldn't have to be repeated for each new
pseudo-field.
> Enable sort by docid
>
>
> Key: SOLR-1478
> URL: https://issues.apache.org/jira/browse/SOLR-1478
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1478.patch
>
>
> Lucene allows sorting by docid, but Solr currently does not provide a way to
> specify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761707#action_12761707 ] Eric Pugh commented on SOLR-1486: - These patch files allow you to start up the Reuters example without using the shell script. Please delete from SVN the ./example/reuters/testdata/download-dataset.sh. Also, please put an svn:ignore on /testdata for *.*. I am assuming that integrating the download process into the ant script is acceptable to work around licensing issues with the Reuters data. Eric > Make getting solrJS running easier. > --- > > Key: SOLR-1486 > URL: https://issues.apache.org/jira/browse/SOLR-1486 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Eric Pugh > Attachments: build.xml.patch, README, ReutersService.java.patch > > > I am attaching a patch for simplifying starting up SolrJS. I found that the > indexing process would break on a bad file, so made the indexing Java class a > bit more robust. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-1486: Attachment: ReutersService.java.patch Skip over badly formed files. > Make getting solrJS running easier. > --- > > Key: SOLR-1486 > URL: https://issues.apache.org/jira/browse/SOLR-1486 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Eric Pugh > Attachments: build.xml.patch, README, ReutersService.java.patch > > > I am attaching a patch for simplifying starting up SolrJS. I found that the > indexing process would break on a bad file, so made the indexing Java class a > bit more robust. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-1486: Attachment: README First cut of a README file to go in root of /javascript > Make getting solrJS running easier. > --- > > Key: SOLR-1486 > URL: https://issues.apache.org/jira/browse/SOLR-1486 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Eric Pugh > Attachments: build.xml.patch, README > > > I am attaching a patch for simplifying starting up SolrJS. I found that the > indexing process would break on a bad file, so made the indexing Java class a > bit more robust. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761697#action_12761697 ] Eric Pugh commented on SOLR-1294: - I would echo Bill's comment of don't let this hold up 1.4. I do have SolrJS working for www.newswise.com/search, however I am struggling with backporting my change. I've shot a day trying to back port the change, and I think I need to wait till my colleague, Michael Herndon, who is the JS Ninja to be back on Monday to sort this out. I will keep plugging on this though. > SolrJS/Javascript client fails in IE8! > -- > > Key: SOLR-1294 > URL: https://issues.apache.org/jira/browse/SOLR-1294 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Eric Pugh >Assignee: Ryan McKinley > Fix For: 1.4 > > Attachments: SOLR-1294-IE8.patch, SOLR-1294.patch, > solrjs-ie8-html-syntax-error.patch > > > SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors > under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. > This happens on both the Sample online site at > http://solrjs.solrstuff.org/test/reuters/ as well as the > /trunk/contrib/javascript library. Seems to be a show stopper from the > standpoint of really using this library! > I have posted a screenshot of the error at > http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png > The error is just a whole bunch of repeated messages in the vein of: > Message: 'jQuery.solrjs' is null or not an object > Line: 24 > Char: 1 > Code: 0 > URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js > Message: 'jQuery.solrjs' is null or not an object > Line: 37 > Char: 1 > Code: 0 > URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js > Message: 'jQuery.solrjs' is null or not an object > Line: 24 > Char: 1 > Code: 0 > URI: > file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js > Message: 'jQuery.solrjs' is null or not an object > Line: 27 > Char: 1 > Code: 0 > URI: > file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-1486: Attachment: build.xml.patch modification to build.xml to download reuters data. > Make getting solrJS running easier. > --- > > Key: SOLR-1486 > URL: https://issues.apache.org/jira/browse/SOLR-1486 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Eric Pugh > Attachments: build.xml.patch > > > I am attaching a patch for simplifying starting up SolrJS. I found that the > indexing process would break on a bad file, so made the indexing Java class a > bit more robust. -- 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-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761699#action_12761699 ] Steven Rowe edited comment on SOLR-1478 at 10/2/09 1:26 PM: Providing aliases would allow all parties to get what they want. Downside: maintenance/documentation issues with multiple syntaxes (minor IMHO). Upside: collision probability goes down even further. *edit* oops, completely wrong on the "upside" -- collision probability actually goes up, not down, since the set of noncolliding field names is reduced by each reserved pseudo-field name. Still, aliases totally rock. was (Author: steve_rowe): Providing aliases would allow all parties to get what they want. Downside: maintenance/documentation issues with multiple syntaxes (minor IMHO). Upside: collision probability goes down even further. > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761699#action_12761699 ] Steven Rowe commented on SOLR-1478: --- Providing aliases would allow all parties to get what they want. Downside: maintenance/documentation issues with multiple syntaxes (minor IMHO). Upside: collision probability goes down even further. > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1486) Make getting solrJS running easier.
Make getting solrJS running easier. --- Key: SOLR-1486 URL: https://issues.apache.org/jira/browse/SOLR-1486 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Eric Pugh I am attaching a patch for simplifying starting up SolrJS. I found that the indexing process would break on a bad file, so made the indexing Java class a bit more robust. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761696#action_12761696 ] Bill Au commented on SOLR-1485: --- Eric, do you think we should support default field and default operator in the QParser used? > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher > Fix For: 1.4 > > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[
https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761694#action_12761694
]
Yonik Seeley commented on SOLR-1478:
{code}
_id_
_docid_
{code}
?
The chance of collision is super low - I'd wager that no one has ever used
__id__ in their schema (single underscores on either side... it's doubled to
prevent wiki syntax from turning it into italics)
> Enable sort by docid
>
>
> Key: SOLR-1478
> URL: https://issues.apache.org/jira/browse/SOLR-1478
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1478.patch
>
>
> Lucene allows sorting by docid, but Solr currently does not provide a way to
> specify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761688#action_12761688 ] Bill Au commented on SOLR-1485: --- Never mind. I just saw you update. Your code looks good. > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher > Fix For: 1.4 > > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- 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-1482) Solr master and slave freeze after query
[
https://issues.apache.org/jira/browse/SOLR-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761677#action_12761677
]
Artem Russakovskii edited comment on SOLR-1482 at 10/2/09 12:45 PM:
Also, just saw this on the first slave:
{noformat}
INFO: Closing searc...@3efceb09 main
fieldValueCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
Oct 2, 2009 11:43:27 AM org.apache.solr.handler.SnapPuller doCommit
INFO: Force open index writer to make sure older index files get deleted
Oct 2, 2009 11:43:35 AM org.apache.solr.update.SolrIndexWriter finalize
SEVERE: SolrIndexWriter was not closed prior to finalize(), indicates a bug --
POSSIBLE RESOURCE LEAK!!!
{noformat}
was (Author: archon810):
Also, just saw this on the first slave:
{quote}
INFO: Closing searc...@3efceb09 main
fieldValueCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
Oct 2, 2009 11:43:27 AM org.apache.solr.handler.SnapPuller doCommit
INFO: Force open index writer to make sure older index files get deleted
Oct 2, 2009 11:43:35 AM org.apache.solr.update.SolrIndexWriter finalize
SEVERE: SolrIndexWriter was not closed prior to finalize(), indicates a bug --
POSSIBLE RESOURCE LEAK!!!
{quote}
> Solr master and slave freeze after query
>
>
> Key: SOLR-1482
> URL: https://issues.apache.org/jira/browse/SOLR-1482
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Nightly 9/28/09.
> 14 individual instances per server, using JNDI.
> replicateAfter commit, 5 min interval polling.
> All caches are currently commented out, on both slave and master.
> Lots of ongoing commits - large chunks of data, each accompanied by a commit.
> This is to guarantee that anything we think is now in Solr remains there in
> case the server crashes.
>Reporter: Artem Russakovskii
>Priority: Critical
> Attachments: catalina.out, catalina2.out
>
>
> We're having issues with the deployment of 2 master-slave setups.
> One of the master-slave setups is OK (so far) but on the other both the
> master and the slave keep freezing, but only after I send a query to them.
> And by freezing I mean indefinite hanging, with almost no output to log, no
> errors, nothing. It's as if there's some sort of a deadlock. The hanging
> servers need to be killed with -9, otherwise they keep hanging.
> The query I send queries all instances at the same time using the ?shards=
> syntax.
> On the slave, the logs just stop - nothing shows up anymore after the query
> is issued. On the master, they're a bit more descriptive. This information
> seeps through very-very slowly, as you can see from the timestamps:
> {quote}
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:16:00 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error processing request
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:39 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "ContainerBackException in thread "pool-29-threadOct 1,
> 2009 2:21:47 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> -22" java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-42" Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError
[jira] Commented: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761687#action_12761687 ] Bill Au commented on SOLR-1485: --- Eric, have you started on this? I recently wrote a QParserPlugin that supports PayloadTermQuery. It is very bear-bone but could be a good starting point. I can attach my code here to get things started. > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher > Fix For: 1.4 > > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1395) Integrate Katta
[ https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Venner (at ning) updated SOLR-1395: - Attachment: solr-1395-1431-4.patch solr-1395-1431-4.patch contains a number of repairs, and now facet count aggregation works. The one down side, is that this patch REQUIRES that the shards paramter explicitly list the shards to be queried, using a wild card does not work. I have this up and running nicely over 9 katta nodes and 65million documents. > Integrate Katta > --- > > Key: SOLR-1395 > URL: https://issues.apache.org/jira/browse/SOLR-1395 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Attachments: hadoop-core-0.19.0.jar, katta-core-0.6-dev.jar, > katta.node.properties, katta.zk.properties, log4j-1.2.13.jar, > solr-1395-1431-3.patch, solr-1395-1431-4.patch, solr-1395-1431.patch, > SOLR-1395.patch, SOLR-1395.patch, SOLR-1395.patch, > test-katta-core-0.6-dev.jar, zkclient-0.1-dev.jar, zookeeper-3.2.1.jar > > Original Estimate: 336h > Remaining Estimate: 336h > > We'll integrate Katta into Solr so that: > * Distributed search uses Hadoop RPC > * Shard/SolrCore distribution and management > * Zookeeper based failover > * Indexes may be built using Hadoop -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1482) Solr master and slave freeze after query
[
https://issues.apache.org/jira/browse/SOLR-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761677#action_12761677
]
Artem Russakovskii commented on SOLR-1482:
--
Also, just saw this on the first slave:
{quote}
INFO: Closing searc...@3efceb09 main
fieldValueCache{lookups=0,hits=0,hitratio=0.00,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumulative_hitratio=0.00,cumulative_inserts=0,cumulative_evictions=0}
Oct 2, 2009 11:43:27 AM org.apache.solr.handler.SnapPuller doCommit
INFO: Force open index writer to make sure older index files get deleted
Oct 2, 2009 11:43:35 AM org.apache.solr.update.SolrIndexWriter finalize
SEVERE: SolrIndexWriter was not closed prior to finalize(), indicates a bug --
POSSIBLE RESOURCE LEAK!!!
{quote}
> Solr master and slave freeze after query
>
>
> Key: SOLR-1482
> URL: https://issues.apache.org/jira/browse/SOLR-1482
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Nightly 9/28/09.
> 14 individual instances per server, using JNDI.
> replicateAfter commit, 5 min interval polling.
> All caches are currently commented out, on both slave and master.
> Lots of ongoing commits - large chunks of data, each accompanied by a commit.
> This is to guarantee that anything we think is now in Solr remains there in
> case the server crashes.
>Reporter: Artem Russakovskii
>Priority: Critical
> Attachments: catalina.out, catalina2.out
>
>
> We're having issues with the deployment of 2 master-slave setups.
> One of the master-slave setups is OK (so far) but on the other both the
> master and the slave keep freezing, but only after I send a query to them.
> And by freezing I mean indefinite hanging, with almost no output to log, no
> errors, nothing. It's as if there's some sort of a deadlock. The hanging
> servers need to be killed with -9, otherwise they keep hanging.
> The query I send queries all instances at the same time using the ?shards=
> syntax.
> On the slave, the logs just stop - nothing shows up anymore after the query
> is issued. On the master, they're a bit more descriptive. This information
> seeps through very-very slowly, as you can see from the timestamps:
> {quote}
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:16:00 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error processing request
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:39 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "ContainerBackException in thread "pool-29-threadOct 1,
> 2009 2:21:47 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> -22" java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-42" Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-26" Exception in thread "http-8080-32"
> Exception in thread "http-8080-25" Exception in thread "http-8080-22"
> Exception in thread "http-8080-15" Exception in thread "http-8080-45"
> Exception in thread "http-8080-13" Exception in thread "http-8080-48"
> Exception in thread "http-8080-7" E
[jira] Updated: (SOLR-1482) Solr master and slave freeze after query
[
https://issues.apache.org/jira/browse/SOLR-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Russakovskii updated SOLR-1482:
-
Attachment: catalina2.out
catalina.out
One thing I forgot to mention - when the hang occurs on the slave, 1 out of 8
CPUs on the machine starts using 100%, which might point in a direction of a
bug rather than a Java memory issue. Remember - the slave never throws those
Java errors to the log, only the master does. The slave just hangs. Using htop,
I can see one of the children java processes use that 100% CPU.
Bill, the appserver log is catalina.out, right? In any case, I'm tailing every
file in the tomcat log dir and that's the log I've been pasting and talking
about.
I've attached 2 full thread dumps after kill -3 (it's quite verbose) on both
slaves (both slaves are affected now).
The first one catalina.out is from the slave that had the Perm limit raised to
512MB, the 2nd one catalina2.out is from the server without any changes to Perm
limits.
> Solr master and slave freeze after query
>
>
> Key: SOLR-1482
> URL: https://issues.apache.org/jira/browse/SOLR-1482
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Nightly 9/28/09.
> 14 individual instances per server, using JNDI.
> replicateAfter commit, 5 min interval polling.
> All caches are currently commented out, on both slave and master.
> Lots of ongoing commits - large chunks of data, each accompanied by a commit.
> This is to guarantee that anything we think is now in Solr remains there in
> case the server crashes.
>Reporter: Artem Russakovskii
>Priority: Critical
> Attachments: catalina.out, catalina2.out
>
>
> We're having issues with the deployment of 2 master-slave setups.
> One of the master-slave setups is OK (so far) but on the other both the
> master and the slave keep freezing, but only after I send a query to them.
> And by freezing I mean indefinite hanging, with almost no output to log, no
> errors, nothing. It's as if there's some sort of a deadlock. The hanging
> servers need to be killed with -9, otherwise they keep hanging.
> The query I send queries all instances at the same time using the ?shards=
> syntax.
> On the slave, the logs just stop - nothing shows up anymore after the query
> is issued. On the master, they're a bit more descriptive. This information
> seeps through very-very slowly, as you can see from the timestamps:
> {quote}
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:16:00 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error processing request
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:39 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "ContainerBackException in thread "pool-29-threadOct 1,
> 2009 2:21:47 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> -22" java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-42" Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-26" Exception in thread "http-8080-32"
> Exception in thread "http-8080-25" Ex
[jira] Updated: (SOLR-1485) PayloadTermQuery support
[
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-1485:
---
Attachment: PayloadTermQueryPlugin.java
This class adds a QParserPlugin to support creating PayloadTermQuery's.
This can be registered in solrconfig.xml like this:
A custom Similarity is needed to score payloads (not provided with this issue).
Once everything is lined up right (payload indexed, similarity with
scorePayload implemented), a query like this can be used:
http://localhost:8983/solr/select?q={!payload%20f=payloads%20func=avg}foo&debugQuery=true
As can be seen with this explanation:
1.4450715 = (MATCH) fieldWeight(payloads:foo in 0), product of:
4.709331 = (MATCH) btq, product of:
0.70710677 = tf(phraseFreq=0.5)
6.66 = scorePayload(...)
0.30685282 = idf(payloads: foo=1)
1.0 = fieldNorm(field=payloads, doc=0)
> PayloadTermQuery support
>
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: PayloadTermQueryPlugin.java
>
>
> Solr currently has no support for Lucene's PayloadTermQuery, yet it has
> support for indexing payloads.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1485) PayloadTermQuery support
PayloadTermQuery support Key: SOLR-1485 URL: https://issues.apache.org/jira/browse/SOLR-1485 Project: Solr Issue Type: New Feature Components: search Reporter: Erik Hatcher Fix For: 1.4 Solr currently has no support for Lucene's PayloadTermQuery, yet it has support for indexing payloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1482) Solr master and slave freeze after query
[
https://issues.apache.org/jira/browse/SOLR-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761654#action_12761654
]
Bill Au commented on SOLR-1482:
---
You probably want to take a JVM thread dump (kill -3) while the JVM is hung to
find out what's going on.
Is your webapp app being reloaded? You can check the appserver log file to see
if that's happening. One common way of running out of PermGen space is a
classloader link which occurs when a webapp is reloaded.
> Solr master and slave freeze after query
>
>
> Key: SOLR-1482
> URL: https://issues.apache.org/jira/browse/SOLR-1482
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Nightly 9/28/09.
> 14 individual instances per server, using JNDI.
> replicateAfter commit, 5 min interval polling.
> All caches are currently commented out, on both slave and master.
> Lots of ongoing commits - large chunks of data, each accompanied by a commit.
> This is to guarantee that anything we think is now in Solr remains there in
> case the server crashes.
>Reporter: Artem Russakovskii
>Priority: Critical
>
> We're having issues with the deployment of 2 master-slave setups.
> One of the master-slave setups is OK (so far) but on the other both the
> master and the slave keep freezing, but only after I send a query to them.
> And by freezing I mean indefinite hanging, with almost no output to log, no
> errors, nothing. It's as if there's some sort of a deadlock. The hanging
> servers need to be killed with -9, otherwise they keep hanging.
> The query I send queries all instances at the same time using the ?shards=
> syntax.
> On the slave, the logs just stop - nothing shows up anymore after the query
> is issued. On the master, they're a bit more descriptive. This information
> seeps through very-very slowly, as you can see from the timestamps:
> {quote}
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:16:00 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:37 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error processing request
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:19:39 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "ContainerBackException in thread "pool-29-threadOct 1,
> 2009 2:21:47 PM org.apache.catalina.connector.CoyoteAdapter service
> SEVERE: An exception or error occurred in the container during the request
> processing
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> -22" java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-42" Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Oct 1, 2009 2:21:47 PM
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler process
> SEVERE: Error reading request, ignored
> java.lang.OutOfMemoryError: PermGen space
> Exception in thread "http-8080-26" Exception in thread "http-8080-32"
> Exception in thread "http-8080-25" Exception in thread "http-8080-22"
> Exception in thread "http-8080-15" Exception in thread "http-8080-45"
> Exception in thread "http-8080-13" Exception in thread "http-8080-48"
> Exception in thread "http-8080-7" Exception in thread "http-8080-38"
> Exception in thread "http-8080-39" Exception in thread "http-8080-28"
> Exception in thread "http-8080-1" Exception in thread "http-8080-2" Exception
> in thread "http-8080-12" Exception in thread "http-8080-44" Exception in
> thread "http-8080-47" Exception in thread "http-8080-29" Exception in thread
> "http-8080-33" Exception in
[jira] Updated: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1221: --- Attachment: SOLR-1221.patch missing "svn add" strikes again attaching new patch. > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1221) Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by default
[ https://issues.apache.org/jira/browse/SOLR-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761643#action_12761643 ] Mark Miller commented on SOLR-1221: --- I was about to merge that last changed needed (rewrite fix) with Yoniks patch - but it looks like Yoniks patch is missing the SolrQueryWrapper class ... > Change Solr Highlighting to use the SpanScorer with MultiTerm expansion by > default > -- > > Key: SOLR-1221 > URL: https://issues.apache.org/jira/browse/SOLR-1221 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1221.patch, SOLR-1221.patch, SOLR-1221.patch, > SOLR-1221.patch, SOLR-1221.patch > > > To improve the out of the box experience of Solr 1.4, I really think we > should make this change. You will still be able to turn both off. > Comments? -- 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-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761641#action_12761641
]
Mark Miller edited comment on SOLR-1475 at 10/2/09 9:59 AM:
Here is a version that is *much* closer to commitable.
*edit*
Couple issues with the test though -
1. in the test, ive still got the teardown commented out - needs to be put back.
2. The wait loop just waits for the snapshot dir to show up - not necessarily
the full copy to be done - just happens to finish fast enough on my machine
anyway
3. Test doesnt test that the reserve works right - I couldn't find a good clean
way to do that without the pause stuff I introduced in the last patch. Tested
it works right with that though. This test just tests that the backup is made
and is a searchable index with all of the docs.
was (Author: markrmil...@gmail.com):
Here is a version that is *much* closer to commitable.
> Java-based replication doesn't properly reserve its commit point during
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to
> replication. Backups seem to work fine on toy indexes. When trying backups
> out on a copy of my production index (300GB-ish), though, I'm getting
> FileNotFoundExceptions. These cancel the backup, and delete the
> snapshot.mmdd* directory. It seems reproducible, in that every time I try
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump. However,
> after a while the snapshot fails. I'll paste in a couple of stack traces
> below.
> I haven't seen any other evidence that my index is corrupt; in particular,
> searching the index and Java-based replication seem to be working fine, and
> the Lucene CheckIndex tool did not report any problems with the index.
>
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1475:
--
Attachment: SOLR-1475.patch
Here is a version that is *much* closer to commitable.
> Java-based replication doesn't properly reserve its commit point during
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to
> replication. Backups seem to work fine on toy indexes. When trying backups
> out on a copy of my production index (300GB-ish), though, I'm getting
> FileNotFoundExceptions. These cancel the backup, and delete the
> snapshot.mmdd* directory. It seems reproducible, in that every time I try
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump. However,
> after a while the snapshot fails. I'll paste in a couple of stack traces
> below.
> I haven't seen any other evidence that my index is corrupt; in particular,
> searching the index and Java-based replication seem to be working fine, and
> the Lucene CheckIndex tool did not report any problems with the index.
>
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1481) phps writer ignores omitHeader parameter
[ https://issues.apache.org/jira/browse/SOLR-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Au resolved SOLR-1481. --- Resolution: Fixed The patch looks good. I have committed it: SendingCHANGES.txt Sendingsrc/java/org/apache/solr/request/PHPSerializedResponseWriter.java Transmitting file data .. Committed revision 821076. Thanks, Jun. > phps writer ignores omitHeader parameter > > > Key: SOLR-1481 > URL: https://issues.apache.org/jira/browse/SOLR-1481 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Koji Sekiguchi >Assignee: Bill Au >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1481.patch > > > My co-worker found this one. I'm expecting a patch will be attached soon by > him. :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields
[
https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761612#action_12761612
]
Grant Ingersoll commented on SOLR-1483:
---
int says:
{quote}
Default numeric field types. For faster range queries, consider the
tint/tfloat/tlong/tdouble types.
Note: the statistics component does not yet work with these field types.
{quote}
tint says:
{quote}
Numeric field types that index each value at various levels of precision
to accelerate range queries when the number of values between the range
endpoints is large. See the javadoc for NumericRangeQuery for internal
implementation details.
Smaller precisionStep values (specified in bits) will lead to more tokens
indexed per value, slightly larger index size, and faster range queries.
Note: faceting does not currently work for these fields.
{quote}
I guess I'd add that in the int case, you could add some "why" to it, but
otherwise, I think both comments explain the case for each one. One gives
faster range queries than the other.
> Example schema is confusing with int, tint and pint fields
> --
>
> Key: SOLR-1483
> URL: https://issues.apache.org/jira/browse/SOLR-1483
> Project: Solr
> Issue Type: Bug
> Components: documentation
>Reporter: Shalin Shekhar Mangar
> Fix For: 1.4
>
>
> Example schema defines int (TrieIntField), tint (TrieIntField) and pint
> (IntField) which is confusing. In particular, the comments for int fields
> tell users to use tint types (which is the same thing).
> Let us remove tint, tlong, tdouble, tdate types from example schemas and fix
> the comments - carefully noting the things trie fields do not work with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1410) remove deprecated custom encoding support in russian/greek analysis
[ https://issues.apache.org/jira/browse/SOLR-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761593#action_12761593 ] Robert Muir commented on SOLR-1410: --- ok, I guess anyway this isn't an issue. if 1.5 goes out with 3.1, RussianLowerCaseFilterFactory can be implemented with LowerCaseFilter, but marked deprecated to be removed in 1.6 > remove deprecated custom encoding support in russian/greek analysis > --- > > Key: SOLR-1410 > URL: https://issues.apache.org/jira/browse/SOLR-1410 > Project: Solr > Issue Type: Task > Components: Analysis >Reporter: Robert Muir >Assignee: Hoss Man >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1410.patch > > > In this case, analyzers have strange encoding support and it has been > deprecated in lucene. > For example someone using CP1251 in the russian analyzer is simply storing Ж > as 0xC6, its being represented as Æ > LUCENE-1793: Deprecate the custom encoding support in the Greek and Russian > Analyzers. If you need to index text in these encodings, please use Java's > character set conversion facilities (InputStreamReader, etc) during I/O, > so that Lucene can analyze this text as Unicode instead. > I noticed in solr, the factories for these tokenstreams allow these > configuration options, which are deprecated in 2.9 to be removed in 3.0 > Let me know the policy (how do you deprecate a config option in solr exactly, > log a warning, etc?) and I'd be happy to create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1481) phps writer ignores omitHeader parameter
[ https://issues.apache.org/jira/browse/SOLR-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761592#action_12761592 ] Bill Au commented on SOLR-1481: --- I can take this one. > phps writer ignores omitHeader parameter > > > Key: SOLR-1481 > URL: https://issues.apache.org/jira/browse/SOLR-1481 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Koji Sekiguchi >Assignee: Bill Au >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1481.patch > > > My co-worker found this one. I'm expecting a patch will be attached soon by > him. :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1481) phps writer ignores omitHeader parameter
[ https://issues.apache.org/jira/browse/SOLR-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Au reassigned SOLR-1481: - Assignee: Bill Au > phps writer ignores omitHeader parameter > > > Key: SOLR-1481 > URL: https://issues.apache.org/jira/browse/SOLR-1481 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Koji Sekiguchi >Assignee: Bill Au >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1481.patch > > > My co-worker found this one. I'm expecting a patch will be attached soon by > him. :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[
https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761585#action_12761585
]
Shalin Shekhar Mangar commented on SOLR-1478:
-
bq. Does this work with distributed search?
No, it throws an exception:
{code}
SEVERE: java.lang.RuntimeException: Doc sort not supported
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.getCachedComparator(ShardDoc.java:171)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.(ShardDoc.java:96)
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:393)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:298)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290)
{code}
> Enable sort by docid
>
>
> Key: SOLR-1478
> URL: https://issues.apache.org/jira/browse/SOLR-1478
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1478.patch
>
>
> Lucene allows sorting by docid, but Solr currently does not provide a way to
> specify it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761584#action_12761584 ] Shalin Shekhar Mangar commented on SOLR-1478: - I don't like having an arbitrary character like '#' signifying a sort type because it does not explain itself to a user. Once 1.4 goes out, it will be public API and we won't be able to change this easily. Erik, please consider this again. This also does not work with distributed search which should be clearly noted wherever we decide to document this. ShardDoc.java line 170 says that it is possible to support it but I'm not sure what Yonik had in mind. > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761583#action_12761583 ] Yonik Seeley commented on SOLR-1478: Does this work with distributed search? > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761581#action_12761581 ] Yonik Seeley commented on SOLR-1478: A few things I don't like about '#' - unlike many other characters, the browser can't encode it for you. For example, I can type in "sort=foo desc" into my browser and it can encode the space for me. If I type in a literal #, Solr will silently truncate the request at that point. People will have trouble with this one. - it can require lexical modification to other parsers (as opposed to semantic modification). Things like function queries or anything else that parse out field names or parameters would need to be modified at the lexical level to accept # - it's generally easier to just check for a special name. - it looks like a comment > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields
[ https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761578#action_12761578 ] Shalin Shekhar Mangar commented on SOLR-1483: - bq. What comments are you referring to? The comments just before int, float, long, double say "For faster range queries, consider the tint/tfloat/tlong/tdouble types." But tint/tfloat/tlong/tdouble are actually the same as int/float/long/double with precisionStep being different. The example schema has 4 types of numeric fields - int/tint/pint/sint. I think we should have only one trie field else we should clearly document why using int is better/different than sint/pint. Without that it would be pretty confusing to a new Solr user who starts off with 1.4 > Example schema is confusing with int, tint and pint fields > -- > > Key: SOLR-1483 > URL: https://issues.apache.org/jira/browse/SOLR-1483 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Shalin Shekhar Mangar > Fix For: 1.4 > > > Example schema defines int (TrieIntField), tint (TrieIntField) and pint > (IntField) which is confusing. In particular, the comments for int fields > tell users to use tint types (which is the same thing). > Let us remove tint, tlong, tdouble, tdate types from example schemas and fix > the comments - carefully noting the things trie fields do not work with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1478. --- Resolution: Fixed > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1484) StatsComponent doesn't properly count missing values for multi-valued facet case
StatsComponent doesn't properly count missing values for multi-valued facet case Key: SOLR-1484 URL: https://issues.apache.org/jira/browse/SOLR-1484 Project: Solr Issue Type: Bug Reporter: Grant Ingersoll Priority: Minor Fix For: 1.5 See SOLR-1471. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1471) StatsComponent does not calculate number missing for facets
[ https://issues.apache.org/jira/browse/SOLR-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1471. --- Resolution: Fixed I committed the fix for the single value case. Committed revision 821014. I don't have good bearings yet on fixing the multivalued case. I am going to open up a new issue and move that to 1.5, unless someone wants to take it up. > StatsComponent does not calculate number missing for facets > --- > > Key: SOLR-1471 > URL: https://issues.apache.org/jira/browse/SOLR-1471 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: James Miller >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: SOLR-1471.patch, SOLR-1471.patch > > > The StatsComponent always returns a missing value of 0 for stats.facet. The > number of missing is calculated for the overall field statistics, but not for > the facets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields
[ https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761569#action_12761569 ] Grant Ingersoll commented on SOLR-1483: --- I'm not following. What comments are you referring to? The comments on the various field types for int, tint and pint are pretty clear to me. > Example schema is confusing with int, tint and pint fields > -- > > Key: SOLR-1483 > URL: https://issues.apache.org/jira/browse/SOLR-1483 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Shalin Shekhar Mangar > Fix For: 1.4 > > > Example schema defines int (TrieIntField), tint (TrieIntField) and pint > (IntField) which is confusing. In particular, the comments for int fields > tell users to use tint types (which is the same thing). > Let us remove tint, tlong, tdouble, tdate types from example schemas and fix > the comments - carefully noting the things trie fields do not work with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Stats Component
Has anyone looked at the memory consumption of Stats Component? Seems like it could be a pig. -Grant
[jira] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761518#action_12761518 ] Erik Hatcher commented on SOLR-1478: I committed, and left the special "field" as "#". I'd rather avoid a string that could potentially be a field name in use, and sorting by docid will be such a specialized case that the encoding confusion won't be too bad. Folks have to deal with URL encoding everywhere anyway. I kinda like that character to mean "number". > Enable sort by docid > > > Key: SOLR-1478 > URL: https://issues.apache.org/jira/browse/SOLR-1478 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1478.patch > > > Lucene allows sorting by docid, but Solr currently does not provide a way to > specify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
[ https://issues.apache.org/jira/browse/SOLR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761496#action_12761496 ] Fergus McMenemie commented on SOLR-1437: I am doing more work on this to: * improve performance by avoiding having to walk back up tree * to review use of putNulls * avoid emitting parent nodes of an emitted record > DIH: Enhance XPathRecordReader to deal with //tagname and other improvments. > > > Key: SOLR-1437 > URL: https://issues.apache.org/jira/browse/SOLR-1437 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Fergus McMenemie >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1437.patch, SOLR-1437.patch > > Original Estimate: 672h > Remaining Estimate: 672h > > As per > http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html > it would be nice to be able to use expressions such as //tagname when > parsing XML documents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1483) Example schema is confusing with int, tint and pint fields
Example schema is confusing with int, tint and pint fields -- Key: SOLR-1483 URL: https://issues.apache.org/jira/browse/SOLR-1483 Project: Solr Issue Type: Bug Components: documentation Reporter: Shalin Shekhar Mangar Fix For: 1.4 Example schema defines int (TrieIntField), tint (TrieIntField) and pint (IntField) which is confusing. In particular, the comments for int fields tell users to use tint types (which is the same thing). Let us remove tint, tlong, tdouble, tdate types from example schemas and fix the comments - carefully noting the things trie fields do not work with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
