[jira] Updated: (SOLR-1481) phps writer ignores omitHeader parameter
[ https://issues.apache.org/jira/browse/SOLR-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Ohtani updated SOLR-1481: - Attachment: SOLR-1481.patch create patch. 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 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-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761488#action_12761488 ] Shalin Shekhar Mangar commented on SOLR-1449: - Hoss, Noble has been refactoring SolrConfig in SOLR-1198 with the end goal being pluggable loading of SolrConfig. This makes SOLR-919 and SOLR-1293 easier. But it is also about how we want SolrPlugins to be loaded. Ideally they'd keep configuration in SolrConfig but the actual loading will happen in SolrCore or somewhere else outside. A large part of work for SOLR-1198 has been done in 1.4. This patch also marked for 1.4 goes against that example by modifying the resource loader. So we need to ask now what is the function of SolrConfig? Do we want it to load/modify SolrResourceLoader objects or just be a representation of configuration? solrconfig.xml syntax to add classpath elements from outside of instanceDir --- Key: SOLR-1449 URL: https://issues.apache.org/jira/browse/SOLR-1449 Project: Solr Issue Type: Improvement Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.4 Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch the idea has been discussed numerous times that it would be nice if there was a way to configure a core to load plugins from specific jars (or classes style directories) by path w/o needing to copy them to the ./lib dir in the instanceDir. The current workaround is symlinks but that doesn't really help the situation of the Solr Release artifacts, where we wind up making numerous copies of jars to support multiple example directories (you can't have reliable symlinks in zip files) -- 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.
[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-tabpanelfocusedCommentId=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] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
Stats Component
Has anyone looked at the memory consumption of Stats Component? Seems like it could be a pig. -Grant
[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-tabpanelfocusedCommentId=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.
[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] 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] 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-tabpanelfocusedCommentId=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] Commented: (SOLR-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.init(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] 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-1481) phps writer ignores omitHeader parameter
[ https://issues.apache.org/jira/browse/SOLR-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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-1482) Solr master and slave freeze after query
[
https://issues.apache.org/jira/browse/SOLR-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 thread http-8080-27 Exception in thread
http-8080-36 Exception in thread http-8080-113 Exception in thread
http-8080-112
[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] 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:
queryParser name=payload
class=org.apache.solr.search.PayloadTermQueryPlugin/
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}foodebugQuery=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] 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 Exception in thread http-8080-22
Exception in thread http-8080-15 Exception in thread
[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-tabpanelfocusedCommentId=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 Exception in thread http-8080-38
Exception in thread http-8080-39 Exception in thread http-8080-28
[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-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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: PermGen space
Oct 1, 2009 2:21:47 PM
[jira] Commented: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (SOLR-1478) Enable sort by docid
[
https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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-1478) Enable sort by docid
[ https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: 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] 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] Commented: (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (SOLR-1478) Enable sort by docid
[
https://issues.apache.org/jira/browse/SOLR-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
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-tabpanelfocusedCommentId=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.
[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=' commit expungeDeletes=true/' )) -- 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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] 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.
