[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1308#comment-1308 ] Uwe Schindler commented on LUCENE-3847: --- As far as I remember, the main problem with the Map interface in Properties is the values coming from the parent object (passed in Parameter). When you wrap another properties object with one that has the other one as defaults given in ctor, then your are fcked up if you are using the Map interface. Which is not the case for system properties, but that's not guaranteed (e.g. the Java JVM could set some basic properties in another Properties object and make the changes available only through the overlayed properties object). To fix the defaults problem I would go with the Enumeration? (works in Java 5, too) in a for(Enumeration? e=propertyNames(); e.hasMoreElements();) loop. If you use the Set interface, the inherited props would not have been seen and the system may *delete* properties which are in a parent/defaults properties object. LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1308#comment-1308 ] Uwe Schindler edited comment on LUCENE-3847 at 3/5/12 8:09 AM: --- As far as I remember, the main problem with the Map interface in Properties is the values coming from the parent defaults object. When you wrap another properties object with one that has the other one as defaults given in ctor, then your are fcked up if you are using the Map interface. Which is not the case for system properties, but that's not guaranteed (e.g. the Java JVM could set some basic properties in another Properties object and make the changes available only through the overlayed properties object). To fix the defaults problem I would go with the Enumeration? (works in Java 5, too) in a for(Enumeration? e=propertyNames(); e.hasMoreElements();) loop. If you use the Set interface, the inherited props would not have been seen and the system may *delete* properties which are in a parent/defaults properties object. was (Author: thetaphi): As far as I remember, the main problem with the Map interface in Properties is the values coming from the parent object (passed in Parameter). When you wrap another properties object with one that has the other one as defaults given in ctor, then your are fcked up if you are using the Map interface. Which is not the case for system properties, but that's not guaranteed (e.g. the Java JVM could set some basic properties in another Properties object and make the changes available only through the overlayed properties object). To fix the defaults problem I would go with the Enumeration? (works in Java 5, too) in a for(Enumeration? e=propertyNames(); e.hasMoreElements();) loop. If you use the Set interface, the inherited props would not have been seen and the system may *delete* properties which are in a parent/defaults properties object. LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1309#comment-1309 ] Dawid Weiss commented on LUCENE-3847: - Yeah, it might have been that that I experienced. So back to enumeration we go :( LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1772) UpdateProcessor to prune empty values
[ https://issues.apache.org/jira/browse/SOLR-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1312#comment-1312 ] Koji Sekiguchi commented on SOLR-1772: -- Hoss: is this same with a part of SOLR-2802 (RemoveBlankFieldUpdateProcessorFactory)? UpdateProcessor to prune empty values --- Key: SOLR-1772 URL: https://issues.apache.org/jira/browse/SOLR-1772 Project: Solr Issue Type: Wish Reporter: Hoss Man Users seem to frequently get confused when some FieldTypes (typically the numeric ones) complain about invalid field values when the inadvertantly index an empty string. It would be cool to provide an UpdateProcessor that makes it easy to strip out any fields being added as empty values ... it could be configured using field (and/or field type) names or globs to select/ignore certain fields -- i haven't thought it through all that hard -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1317#comment-1317 ] Uwe Schindler edited comment on LUCENE-3847 at 3/5/12 8:30 AM: --- About your commit: It should be getProperty() [without cast] and not get()... Otherwise the defaults are again fcked up :-) was (Author: thetaphi): About your commit: It should be getProperty() and not get()... Otherwise the defaults are again fcked up :-) LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1317#comment-1317 ] Uwe Schindler commented on LUCENE-3847: --- About your commit: It should be getProperty() and not get()... Otherwise the defaults are again fcked up :-) LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1320#comment-1320 ] Dawid Weiss commented on LUCENE-3847: - Right, good catch. Properties are seriously messed up, aren't they? LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2437) Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true
[ https://issues.apache.org/jira/browse/SOLR-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-2437. -- Resolution: Fixed Fix Version/s: 4.0 This has been fixed and committed in part of SOLR-2193 and its related issues. Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true --- Key: SOLR-2437 URL: https://issues.apache.org/jira/browse/SOLR-2437 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Koji Sekiguchi Priority: Minor Fix For: 4.0 Attachments: SOLR-2437.patch Use just IW.deleteAll() to abort background merges, remove buffered docs, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1323#comment-1323 ] Uwe Schindler commented on LUCENE-3847: --- Horrible!!! I just say: die, die, die LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3188) New admin page: Enable Polling button disappears after disabling polling and reloading page
[
https://issues.apache.org/jira/browse/SOLR-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1322#comment-1322
]
Stefan Matheis (steffkes) commented on SOLR-3188:
-
Neil, i've checked that .. and the only part in the code where the error-box on
the replication get's activated is this:
https://github.com/steffkes/solr-admin/blob/master/js/scripts/replication.js#L89
. so, i guess the easiest thing to try is, to request the replication urls
manually and see what the response is.
{{/replication?command=disablereplicationwt=json}} and maybe additionally
{{/replication?command=detailswt=json}} afterwards
New admin page: Enable Polling button disappears after disabling polling
and reloading page
-
Key: SOLR-3188
URL: https://issues.apache.org/jira/browse/SOLR-3188
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Neil Hooey
Priority: Minor
Labels: admin
When you go to this URL on a slave:
http://localhost:8983/solr/#/singlecore/replication
And click the Disable Polling button, you see a red bar that says
invalid_master. I'm not sure why I get this red bar, as I haven't tested it
outside of my own installation, but it seems normal.
If you then refresh the page, the Replicate Now and Enable Polling
buttons disappear. It seems like their generation is being interrupted by the
invalid_master error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1325#comment-1325 ] Dawid Weiss commented on LUCENE-3847: - bq. As far as I remember, the main problem with the Map interface in Properties is the values coming from the parent defaults object. Exactly, I'm kind of slow today. LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[
https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1324#comment-1324
]
Dawid Weiss commented on LUCENE-3847:
-
Now I remember what it was that I had a problem with. Properties has the notion
of defaults so it falls back to another Properties by default if the key is
not present. Unfortunately get() is not overridden in Properties (and
everything else is) so things like propertyNames or getProperty will return a
value from the fallback set, but get() won't.
{code}
public static void main(String[] args) {
Properties defaults = new Properties();
Properties p = new Properties(defaults);
String key = custom-key;
String value = value;
defaults.put(key, value);
for (Enumeration? e = p.propertyNames(); e.hasMoreElements();) {
Object currentKey = e.nextElement();
if (currentKey == key) {
System.out.println(Default key found in propertyNames(), but...);
System.out.println(p.get()= + p.get(key));
System.out.println(p.getProperty()= + p.getProperty(key));
}
}
}
{code}
You can easily corrupt other programs by inserting Object values into the
system property set -- any enumeration will then fail with a classcast. Still
don't remember where this caused a problem but it definitely was.
LuceneTestCase should check for modifications on System properties
--
Key: LUCENE-3847
URL: https://issues.apache.org/jira/browse/LUCENE-3847
Project: Lucene - Java
Issue Type: Improvement
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
Fix For: 3.6, 4.0
Attachments: LUCENE-3847.patch
- fail the test if changes have been detected.
- revert the state of system properties before the suite.
- cleanup after the suite.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3846) Fuzzy suggester
[ https://issues.apache.org/jira/browse/LUCENE-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1328#comment-1328 ] Eks Dev commented on LUCENE-3846: - Robert, I am not talking from some abstract-theoretical point of view, I made my own experience on nontrivial Lucene datasets that are unfortunately not for sharing. Having possibility to train cost matrices per edit operation brings a lot, but you may have had another experience (different problems, different data...). Without specifying concrete task (annotated data), there is no notion of better, so this argument simply does not help (show me it is better, no you show me all ones matrix is better than any other, no, no...). It is simply about the experience we made in the past, different opinions. I personally would not try this argument with molecular biology teams, and tell them their POM and BLOSUM matrices are worthless or to someone in record linkage community (Lucene was used in this context a lot) or ... Fuzzy suggester --- Key: LUCENE-3846 URL: https://issues.apache.org/jira/browse/LUCENE-3846 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3846.patch Would be nice to have a suggester that can handle some fuzziness (like spell correction) so that it's able to suggest completions that are near what you typed. As a first go at this, I implemented 1T (ie up to 1 edit, including a transposition), except the first letter must be correct. But there is a penalty, ie, the corrected suggestion needs to have a much higher freq than the exact match suggestion before it can compete. Still tons of nocommits, and somehow we should merge this / make it work with analyzing suggester too (LUCENE-3842). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1330#comment-1330 ] Uwe Schindler commented on LUCENE-3847: --- No prob. That is exactly the problem I wanted to prevent with the Enumeration and getProperty(). Code using those 2 functions is the only correct one to list all properties... :( LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3195) timeAllowed is ignored for grouping queries
[
https://issues.apache.org/jira/browse/SOLR-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1345#comment-1345
]
Martijn van Groningen commented on SOLR-3195:
-
The difference between the elapsed time and qtime is that the first also takes
into account the time spend on the trip from and to the shard where the shard
request is executed. I think it is fine to include also this time in the time
allowed for a query.
timeAllowed is ignored for grouping queries
---
Key: SOLR-3195
URL: https://issues.apache.org/jira/browse/SOLR-3195
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 3.5, 4.0
Reporter: Russell Black
Assignee: Martijn van Groningen
Labels: patch
Attachments: SOLR-3195-timeallowed-for-grouping-3x-backport.patch,
SOLR-3195-timeallowed-for-grouping.patch,
SOLR-3195-timeallowed-for-grouping.patch
For grouping queries, the {{timeAllowed}} parameter is ignored. I couldn't
find this limitation documented anywhere, and we would like to use that
feature in our production system. I have created a patch that makes grouping
queries respect the {{timeAllowed}} parameter. The test cases all pass, and
it and it seems to work well. I added support for both distributed and
non-distributed grouping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3195) timeAllowed is ignored for grouping queries
[
https://issues.apache.org/jira/browse/SOLR-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen updated SOLR-3195:
Fix Version/s: 4.0
3.6
timeAllowed is ignored for grouping queries
---
Key: SOLR-3195
URL: https://issues.apache.org/jira/browse/SOLR-3195
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 3.5, 4.0
Reporter: Russell Black
Assignee: Martijn van Groningen
Labels: patch
Fix For: 3.6, 4.0
Attachments: SOLR-3195-timeallowed-for-grouping-3x-backport.patch,
SOLR-3195-timeallowed-for-grouping.patch,
SOLR-3195-timeallowed-for-grouping.patch
For grouping queries, the {{timeAllowed}} parameter is ignored. I couldn't
find this limitation documented anywhere, and we would like to use that
feature in our production system. I have created a patch that makes grouping
queries respect the {{timeAllowed}} parameter. The test cases all pass, and
it and it seems to work well. I added support for both distributed and
non-distributed grouping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-trunk - Build # 1783 - Still Failing
Build: https://builds.apache.org/job/Solr-trunk/1783/ 1 tests failed. FAILED: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:809) at org.apache.lucene.util.LuceneTestCase.access$1100(LuceneTestCase.java:137) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:633) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:531) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:593) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:837) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:781) Build Log (for compile errors): [...truncated 9979 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3195) timeAllowed is ignored for grouping queries
[
https://issues.apache.org/jira/browse/SOLR-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen resolved SOLR-3195.
-
Resolution: Fixed
Committed to trunk and 3x branch.
timeAllowed is ignored for grouping queries
---
Key: SOLR-3195
URL: https://issues.apache.org/jira/browse/SOLR-3195
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 3.5, 4.0
Reporter: Russell Black
Assignee: Martijn van Groningen
Labels: patch
Fix For: 3.6, 4.0
Attachments: SOLR-3195-timeallowed-for-grouping-3x-backport.patch,
SOLR-3195-timeallowed-for-grouping.patch,
SOLR-3195-timeallowed-for-grouping.patch
For grouping queries, the {{timeAllowed}} parameter is ignored. I couldn't
find this limitation documented anywhere, and we would like to use that
feature in our production system. I have created a patch that makes grouping
queries respect the {{timeAllowed}} parameter. The test cases all pass, and
it and it seems to work well. I added support for both distributed and
non-distributed grouping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. - Thread leaks will result in a failure (add lingering if needed, but no ignores). [this is done, but disabled] - Add a validator for @Test method overrides (check how many of these we already have first). - What to do with thread-shared Random instances copies in MockIndexWriter and MockAnalyzer? was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. - Thread leaks will result in a failure (add lingering if needed, but no ignores). [this is done, but disabled] - Add a validator for @Test method overrides (check how many of these we already have first). Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks. Key: LUCENE-3808 URL: https://issues.apache.org/jira/browse/LUCENE-3808 Project: Lucene - Java Issue Type: Sub-task Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. - Thread leaks will result in a failure (add lingering if needed, but no ignores). [this is done, but disabled] - Add a validator for @Test method overrides (check how many of these we already have first). - What to do with thread-shared Random instances copies in MockIndexWriter and MockAnalyzer? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of generics
violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1371#comment-1371
]
Uwe Schindler commented on LUCENE-3850:
---
This also makes the eclipse compiler more silent, because rawtypes was ported
from the eclipse compiler to Java 7.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3154) SolrJ CloudServer should be leader and network aware when adding docs
[ https://issues.apache.org/jira/browse/SOLR-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-3154: -- Description: It would be good when indexing if the SolrJ CloudServer was leader aware so that we could avoid doing an extra hop for the data. It would also be good if one could easily set things up based on data locality principles. This might mean that CloudServer is aware of where on the network it is and would pick leaders that are as close as possible (i.e. local, perhaps.) This would come in to play when working with tools like Hadoop or other grid computing frameworks. (was: It would be good when indexing if the SolrJ CloudServer was leader aware so that we could avoid doing an extra hop for the data.) Summary: SolrJ CloudServer should be leader and network aware when adding docs (was: SolrJ CloudServer should be leader aware when adding docs) SolrJ CloudServer should be leader and network aware when adding docs - Key: SOLR-3154 URL: https://issues.apache.org/jira/browse/SOLR-3154 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0 Reporter: Grant Ingersoll Priority: Minor Fix For: 4.0 It would be good when indexing if the SolrJ CloudServer was leader aware so that we could avoid doing an extra hop for the data. It would also be good if one could easily set things up based on data locality principles. This might mean that CloudServer is aware of where on the network it is and would pick leaders that are as close as possible (i.e. local, perhaps.) This would come in to play when working with tools like Hadoop or other grid computing frameworks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: errata for solr tutorial
Hi, Thanks for reporting. This is fixed now on the staging site, will be set live soon. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 1. mars 2012, at 16:50, Nicolai Scheer wrote: Hi! Having just worked through the solr tutorial (http://lucene.apache.org/solr/tutorial.html) I think I found two minor bugs: 1. The delete by query example java -Ddata=args -jar post.jar deletequeryname:DDR/query/delete should read java -Ddata=args -jar post.jar deletequeryname:DDR/query/delete 2. The link to the mailing lists at the end of the tutorial seems to be dead as of now: http://lucene.apache.org/solr/mailing_lists.html Greetings, Nico - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: errata for solr tutorial
I checked in the two changes but did not push live, seems like someone else is in the process of cleaning up the tutorial too. http://lucene.staging.apache.org/solr/tutorial.html -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 5. mars 2012, at 13:10, Jan Høydahl wrote: Hi, Thanks for reporting. This is fixed now on the staging site, will be set live soon. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 1. mars 2012, at 16:50, Nicolai Scheer wrote: Hi! Having just worked through the solr tutorial (http://lucene.apache.org/solr/tutorial.html) I think I found two minor bugs: 1. The delete by query example java -Ddata=args -jar post.jar deletequeryname:DDR/query/delete should read java -Ddata=args -jar post.jar deletequeryname:DDR/query/delete 2. The link to the mailing lists at the end of the tutorial seems to be dead as of now: http://lucene.apache.org/solr/mailing_lists.html Greetings, Nico - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3846) Fuzzy suggester
[
https://issues.apache.org/jira/browse/LUCENE-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222303#comment-13222303
]
Robert Muir commented on LUCENE-3846:
-
{quote}
I personally would not try this argument with molecular biology teams, and tell
them their POM and BLOSUM matrices are worthless or to someone in record
linkage community (Lucene was used in this context a lot) or ...
{quote}
Thats ok, I would :)
I don't think we should complicate already-complicated things unless there is
some clear benefit.
I'm not worried about offending anyone.
Fuzzy suggester
---
Key: LUCENE-3846
URL: https://issues.apache.org/jira/browse/LUCENE-3846
Project: Lucene - Java
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.6, 4.0
Attachments: LUCENE-3846.patch
Would be nice to have a suggester that can handle some fuzziness (like spell
correction) so that it's able to suggest completions that are near what you
typed.
As a first go at this, I implemented 1T (ie up to 1 edit, including a
transposition), except the first letter must be correct.
But there is a penalty, ie, the corrected suggestion needs to have a much
higher freq than the exact match suggestion before it can compete.
Still tons of nocommits, and somehow we should merge this / make it work with
analyzing suggester too (LUCENE-3842).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-3846) Fuzzy suggester
For that matter, I am worried not to offend anyone, just that type of person :)
But expressing his opinion, just as we did here has nothing to do with
it. Hope you did not read my comments as offending, this was by no
means my intention.
Just do not complain later, I warned you, molecular biologists can be
mean if you touch their matrices :)
(I took it on mailing list, as it adds only noise to Jira)
On Mon, Mar 5, 2012 at 1:38 PM, Robert Muir (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222303#comment-13222303
]
Robert Muir commented on LUCENE-3846:
-
{quote}
I personally would not try this argument with molecular biology teams, and
tell them their POM and BLOSUM matrices are worthless or to someone in record
linkage community (Lucene was used in this context a lot) or ...
{quote}
Thats ok, I would :)
I don't think we should complicate already-complicated things unless there is
some clear benefit.
I'm not worried about offending anyone.
Fuzzy suggester
---
Key: LUCENE-3846
URL: https://issues.apache.org/jira/browse/LUCENE-3846
Project: Lucene - Java
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.6, 4.0
Attachments: LUCENE-3846.patch
Would be nice to have a suggester that can handle some fuzziness (like spell
correction) so that it's able to suggest completions that are near what
you typed.
As a first go at this, I implemented 1T (ie up to 1 edit, including a
transposition), except the first letter must be correct.
But there is a penalty, ie, the corrected suggestion needs to have a much
higher freq than the exact match suggestion before it can compete.
Still tons of nocommits, and somehow we should merge this / make it work
with analyzing suggester too (LUCENE-3842).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3850:
--
Attachment: LUCENE-3850-part1.patch
Patch that fixes most warnings in Lucene Core and modules. Partly also Solr.
I will commit this now as it gets outdated soon. Will then backport / ask
eclipse to fix 3.x.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222344#comment-13222344
]
Uwe Schindler commented on LUCENE-3850:
---
Committed trunk Revision: 1297048
Now backporting...
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222345#comment-13222345
]
Uwe Schindler commented on LUCENE-3850:
---
Btw, I also changed lots of non-rawtypes warnings like accessing static fields
on wrong type (subclass or more horrible, with instance). This was also
producing warning in Java 7.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3838) IndexWriter.maybeMerge() removes deleted documents from index (Lucene 3.1.0 to 3.5.0)
[
https://issues.apache.org/jira/browse/LUCENE-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222347#comment-13222347
]
Ivan Stojanovic commented on LUCENE-3838:
-
Hi Michael,
of course this happens in version 3.1.0 as stated in the title (in parentheses).
Actually, it has never been stated that this is an internal implementation
detail (if I can remember correctly). I'm very sure that we are not the only
ones who were relying on this behavior. Also, this backward compatibility break
wasn't stated in 3.1.0 changes log.
Anyway, we already have an ID field but we can't rely on it for long running
operations. Suppose that an index export is in progress while there is a bunch
of add/delete/search operations. Or worse, suppose that a batch delete is in
progress (driven by a filter criteria) at the same time. I have to say here
that we are using only one searcher per index here and also we are working with
farms of indexes with size of 3-5 millions of documents per index. I can't even
imagine the use of more than one searcher per index here. One searcher per
index also gives us the best performance which is our top concern. Another
thing. When an admin performs optimization then the index is locked so no one
can access it in order to avoid disk overuse.
We also have a deletes filter :)
It is used as a ram filter that buffers deletes using BitSet and occasionally
flushing this buffer to index (deleting documents marked as deletes). This
gives us the lightning performance related to both deleting documents and
search operation relying on a custom Collector wrapping this filter. If we used
an application filter to skip documents than the search would suffer a
significant slow down because of communication with an application filter for
each document retrieved from index. if we do this than our ultra fast Lucene
driven application loses its sense.
The suggestion with a custom codec sounds very promising. I only don't
understand if we will have to wait for a Lucene 4.0 release for a custom codec
implementation (with maybe an API that allows that) or I need to implement it
for Lucene trunk. If I need to implement it for trunk than can you please give
me a starting point where to begin from? I must say that I haven't dived deep
in Lucene merge functionality. Also, can this approach differentiate between
maybeMerge() and forceMerge(). We need to support document removal in
forceMerge(), of course.
Greatest regards,
Ivan
IndexWriter.maybeMerge() removes deleted documents from index (Lucene 3.1.0
to 3.5.0)
-
Key: LUCENE-3838
URL: https://issues.apache.org/jira/browse/LUCENE-3838
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
Environment: Windows, Linux, OSX
Reporter: Ivan Stojanovic
Priority: Blocker
Labels: api-change
Attachments: TempTest.java
My company uses Lucene for high performance, heavy loaded farms of
translation repositories with hundreds of simultaneous
add/delete/update/search/retrieve threads. In order to support this complex
architecture beside other things and tricks used here I rely on docId-s being
unchanged until I ask that explicitly (using IndexWriter.optimize() -
IndexWriter.forceMerge()).
For this behavior LogMergePolicy is used.
This worked fine until we raised the Lucene version from 3.0.2 to 3.5.0.
Until version 3.1.0 merge triggerred by IndexWriter.addDocument() didn't
expunge deleted documents ensuring that docId-s stayed unchanged and making
some critical jobs possible without impact on index size.
IndexWriter.optimize() did the actual deleted documents removal.
From Lucene version 3.1.0 IndexWriter.maybeMerge() does the same thing as
IndexWriter.forceMerge() regarding deleted documents. There is no difference.
This leads to unpredictable internal index structure changes during simple
document add (and possible delete) operations and in undefined point in time.
I looked into the Lucene source code and can definitely confirm this.
This issue makes our Lucene client code totally unusable.
Solution steps:
1) add a flag somewhere that will control whether the deleted documents
should be removed in maybeMerge(). Note that this is only a half of what we
need here.
2) make forceMerge() always remove deleted documents no matter if
maybeMerge() removes them or not. Alternatively, there can be another
parameter added to forceMerge() that will also tell if deleted documents
should be removed from index or not.
The sample JUnit code that can replicate this issue is added below.
public class TempTest {
private Analyzer _analyzer = new
[jira] [Commented] (SOLR-3011) DIH MultiThreaded bug
[ https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222354#comment-13222354 ] Wenca Petr commented on SOLR-3011: -- The problem was that the first thread that reached the end of data set the iterator to null and when other thread called SqlEntityProcessor.nextRow() then all the data to be indexed were loaded again and all the documents were analysed again because SqlEntityProcessor.nextRow() tests the iterator to be null (assuming that null means the beginning of the process). By the change a made all the threads then receive null from the iterator, so they know that there are no more data. Is this explanation ok? DIH MultiThreaded bug - Key: SOLR-3011 URL: https://issues.apache.org/jira/browse/SOLR-3011 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 3.5, 4.0 Reporter: Mikhail Khludnev Priority: Minor Fix For: 4.0 Attachments: SOLR-3011.patch, SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch current DIH design is not thread safe. see last comments at SOLR-2382 and SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly it's a SOLR-2947 patch from 28th Dec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3154) SolrJ CloudServer should be leader and network aware when adding docs
[ https://issues.apache.org/jira/browse/SOLR-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222359#comment-13222359 ] Mark Miller commented on SOLR-3154: --- The main difficulty here is that to get the readable to indexed id that we hash, we need the field type and the id field. The id field we can simply have the user supply - but technically each field type can impl a custom method to get the indexed id that we hash on. Not sure what we do about this, but initially I was thinking we could support one or two field types (int, string) and just copy the (simple) logic for these two types into the server impl. Then the user would also have to supply the type (int,string) of the id field as well - though we could default it to what the example schema uses. SolrJ CloudServer should be leader and network aware when adding docs - Key: SOLR-3154 URL: https://issues.apache.org/jira/browse/SOLR-3154 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0 Reporter: Grant Ingersoll Priority: Minor Fix For: 4.0 It would be good when indexing if the SolrJ CloudServer was leader aware so that we could avoid doing an extra hop for the data. It would also be good if one could easily set things up based on data locality principles. This might mean that CloudServer is aware of where on the network it is and would pick leaders that are as close as possible (i.e. local, perhaps.) This would come in to play when working with tools like Hadoop or other grid computing frameworks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3847) LuceneTestCase should check for modifications on System properties
[ https://issues.apache.org/jira/browse/LUCENE-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222361#comment-13222361 ] Mark Miller commented on LUCENE-3847: - This is great Dawid, thanks! LuceneTestCase should check for modifications on System properties -- Key: LUCENE-3847 URL: https://issues.apache.org/jira/browse/LUCENE-3847 Project: Lucene - Java Issue Type: Improvement Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3847.patch - fail the test if changes have been detected. - revert the state of system properties before the suite. - cleanup after the suite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3778) Create a grouping convenience class
[
https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222368#comment-13222368
]
Martijn van Groningen commented on LUCENE-3778:
---
{quote}
One can actually use GroupingSearch in a shard'd env, on each shard,
right? It's just that then you merge them like normal on the front
end (ie, TopGroups.merge). Is that the only reason for the ... in a
non distributed environment javadoc warning?
{quote}
In a sharded env one needs to first execute all the first pass collector on all
shards, merge the returned search groups, execute the second pass search (with
the top N merged search groups as argument) on most of the shards and finally
merge the TopGroups from all shards into a topN TopGroups. Also grouping by
docblock and grouping features like allGroups and groupHead don't work in a
normal sharded environment (unless you partition the groups properly). The docs
caching also only makes sense when performing grouping on a local index. This
usage is very different then non distributed grouping, that is why I think it
is better to have a separate grouping convenience class for distributed
grouping (DistributedGroupSearch?).
bq. Maybe the ctor should take docValuesType / diskResidentValues
Makes sense!
bq. Maybe you should pass the groupSort, groupsOffset, groupsLimit to the
search method (instead of setters)?
Maybe we just should have defaults for these options? Sort.RELEVANCE, 0 and 10?
Create a grouping convenience class
---
Key: LUCENE-3778
URL: https://issues.apache.org/jira/browse/LUCENE-3778
Project: Lucene - Java
Issue Type: Improvement
Components: modules/grouping
Reporter: Martijn van Groningen
Attachments: LUCENE-3778.patch
Currently the grouping module has many collector classes with a lot of
different options per class. I think it would be a good idea to have a
GroupUtil (Or another name?) convenience class. I think this could be a
builder, because of the many options
(sort,sortWithinGroup,groupOffset,groupCount and more) and implementations
(term/dv/function) grouping has.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3850:
--
Attachment: LUCENE-3850-part1-branch3x.patch
Patch for 3.x (affecting also Lucene Core mainly, parts of Solr). Still contrib
is (like in trunk) on TODO list (especially grouping!).
Will commit now.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch, LUCENE-3850-part1.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222374#comment-13222374
]
Uwe Schindler commented on LUCENE-3850:
---
Committed 3.x revision: 1297074
I will keep this issue open for more cleanups.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch, LUCENE-3850-part1.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222379#comment-13222379 ] Yonik Seeley commented on SOLR-2719: I've been saying for a while that using roughly java identifiers for field names was best practice, but we should document it somewhere. I don't think we should change StrParser.getId to be more permissive though - that will just cause more problems in the future (say when we want to start adding infix and want a-b to be a minus b. There's not a regression in that specific code since the function parser has never accepted - as part of a field name. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3134) Include shard Information in response
[ https://issues.apache.org/jira/browse/SOLR-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222381#comment-13222381 ] Russell Black commented on SOLR-3134: - Ryan, Are you still planning to commit the 3x patch? We'd love to have this feature in 3.6. Include shard Information in response - Key: SOLR-3134 URL: https://issues.apache.org/jira/browse/SOLR-3134 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3134-shard-info-3_5-backport.patch, SOLR-3134-shard-info-3_x-backport.patch, SOLR-3134-shard-info-fix.patch, SOLR-3134-shard-info.patch For distributed search where each shard represents a logically different index (or physical location), it would be great to know the hit count for each shard. In addition, it would be nice to get error info for each shard rather then aborting the whole request when something fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222394#comment-13222394 ] Luca Cavanna commented on SOLR-2719: Yonik, I see your point. On the other hand, the dash is a widely used character within field names. The regression is on the Solr behaviour, and I think it's pretty annoying from a user perspective. Anyway, if that's the direction of the project, no problem. What matters more than anything else is consistency. We should document it somewhere as you wrote, but I'd also propose a field names validation at Solr startup, using the StrParser rules, so that Solr accepts only allowed field names and can guarantee the proper behaviour with all allowed field names. What do you think? REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222401#comment-13222401 ] Mark Miller commented on SOLR-2719: --- bq. but I'd also propose a field names validation at Solr startup, +1 - rather than playing loosey goosey on what's a valid field name, we should doc and validate for it explicitly. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[
https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222408#comment-13222408
]
Yonik Seeley commented on SOLR-2719:
bq. Yonik, I see your point. On the other hand, the dash is a widely used
character within field names. The regression is on the Solr behaviour, and I
think it's pretty annoying from a user perspective.
The easiest way to handle this would be this code in ReturnFields:
{code}
// short circuit test for a really simple field name
String key = null;
String field = sp.getId(null);
char ch = sp.ch();
{code}
Instead of using getId, we should hand-roll something that also accepts - as
part of the field name. That would leave function parser (and other users of
getId) alone, but allow fieldnames with dashes in the fl param.
bq. What matters more than anything else is consistency.
If we really want to go for consistency, then we should not accept - anywhere
(rather than attempting to expand it to everywhere).
REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing
fl=my-field-name type usecases
-
Key: SOLR-2719
URL: https://issues.apache.org/jira/browse/SOLR-2719
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Reporter: Nik V. Babichev
Priority: Blocker
Labels: field, fl, query, queryparser
Fix For: 4.0
Attachments: SOLR-2719.patch
fl=my-hyphen-field in query params parsed as my instead of
my-hyphen-field.
OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing
in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.')
Hyphen is not JavaIdentifierPart and this check break when first - is found.
This problem solve by passing '-' to check:
if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break;
But I don't know how it can affect on whole project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3201) Recurrence resolver into VariableResolver
Recurrence resolver into VariableResolver
-
Key: SOLR-3201
URL: https://issues.apache.org/jira/browse/SOLR-3201
Project: Solr
Issue Type: Bug
Environment: solr 3.1 solr dataimport 3.3.0
Reporter: adrien ruffie
Hello I have the following delta query:
${dataimporter.functions.formatDate(${dataimporter.last_index_time}, 'MMdd
HH:mm:ss:SSS')}
but during the VariableResolverImpl.resolve() the following action
String[] parts = DOT_SPLIT.split(name, 0);
CURRENT_VARIABLE_RESOLVER.set(this);
split with '.' but the two recursive calling to ${dataimporter.last_index_time}
in the first ${dataimporter.functions.formatDate()} isn't take into account.
Do you have a work around ?
Thank you
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3778) Create a grouping convenience class
[ https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated LUCENE-3778: -- Attachment: LUCENE-3778.patch Updated patch. * Added jdocs. * allGroups and allGroupHeads methods are implemented now. Create a grouping convenience class --- Key: LUCENE-3778 URL: https://issues.apache.org/jira/browse/LUCENE-3778 Project: Lucene - Java Issue Type: Improvement Components: modules/grouping Reporter: Martijn van Groningen Attachments: LUCENE-3778.patch, LUCENE-3778.patch Currently the grouping module has many collector classes with a lot of different options per class. I think it would be a good idea to have a GroupUtil (Or another name?) convenience class. I think this could be a builder, because of the many options (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations (term/dv/function) grouping has. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222443#comment-13222443 ] Luca Cavanna commented on SOLR-2719: How about trying to achieve both? I mean, are there many other places where we should do the same (adding the dash support)? QueryParsing#parseSort has the same problem. Anything else? I'm probably missing something. Depending on where we need to add support for dash to add consistency, I would try to add support for the trailing dash here for backward compatibility (I'd have a patch almost ready), and work on validation as well. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cooper updated SOLR-2894: - Attachment: distribPatch-05-03-12.txt Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Attachments: distribPatch-05-03-12.txt Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222449#comment-13222449 ] Yonik Seeley commented on SOLR-2719: bq. How about trying to achieve both? I mean, are there many other places where we should do the same (adding the dash support)? I think this regression is limited to fl since that code was changed to support pseudo-fields. bq. QueryParsing#parseSort has the same problem. I just tried trunk with sort=a-b_s desc and it seemed to work fine. REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222450#comment-13222450 ] Dan Cooper commented on SOLR-2894: -- Added a patch to provide distributed pivot faceting. We've been running this code for a while now and it seems to work OK, also created a unit test to test distributed pivot faceting on a small set of data. The patch was created against Solr trunk revision 1297102. It should perform in much the same way as single shard pivot faceting. It only sorts by count if you specify that option otherwise it returns results in the order they were generated (may be useful is performance is important but ordering is not). Most will want to specify facet.sort=count. This patch also supports limiting results using facet.limit. To do the merge I'm converting the NamedList objects that get returned by each shard in a giant map (should be more efficient for merging the results) and then converting back into a NamedList when the merge is complete. This merge should support N depth pivots but I've only properly tested a depth of 2. I've added some new parameters to support the features we require from pivot faceting and thought they may as well go in the patch in case others find them useful. * facet.pivot.limit.method ** set to 'combined' if you want only the N number of top results to be returned across all pivots, where N is set by facet.limit. e.g. if you pivoted by country,manufacturer and limited by 5, obviously the top 5 countries would be returned, but only the top 5 manufacturers by combined total would be returned too. e.g. Each country would return the same 5 manufacturers (or less if no results). * facet.pivot.limit.ignore ** Ignores the specified field from the limiting operations. e.g. if you pivoted by country,manufacturer and limited by 5 and set facet.pivot.limit.ignore=country then you would get all available countries returned (not limited) but only 5 manufacturers for each country. Can someone test the patch and give some feedback? Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Attachments: distribPatch-05-03-12.txt Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cooper updated SOLR-2894: - Attachment: (was: distribPatch-05-03-12.txt) Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cooper updated SOLR-2894: - Attachment: (was: SOLR-2894.patch) Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cooper updated SOLR-2894: - Attachment: SOLR-2894.patch Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cooper updated SOLR-2894: - Attachment: SOLR-2894.patch Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Affects Versions: 4.0 Reporter: Erik Hatcher Attachments: SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2660) omitPositions improvements
[ https://issues.apache.org/jira/browse/SOLR-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222461#comment-13222461 ] Robert Muir commented on SOLR-2660: --- I think this could be a good option (in combination with shingles as mentioned), to accelerate the phrase queries that solr query parsers generate in order to boost closer matches. Again the idea is to omit positions entirely, and instead use shinglefilter (unigrams and bigrams), approximating phrase queries with n-gram conjunctions. I think for the sloppy case, we should use an n-gram disjunction, perhaps interpreting slop factor as minNrShouldmatch? This basically means you are substituting levenshtein distance for an n-gram approximation in both cases. In general its a classic indexing/search tradeoff, in my tests on wikipedia indexing takes ~ twice as long with the shingles, but the tradeoff is that for a lot of these use cases you don't need to consult the positions file at all. As a parameter to the fieldtype its easily pluggable without messing with any queryparsers, and ordinary queries (term, boolean, etc) are totally 'pass-thru', *however* the thing I guess I don't like about this patch is the fact that this is really a different 'query intent', in other words, I think its a perfect approach when you just want to boost scores of close matches (e.g. when generated by dismax queryparser), but when your 'intent' is to actually limit matches to a phrase (e.g. when keyed in by a user directly), then this approximation isn't as good of a fit. Either way I'm open to other opinions before doing anything (if we decide to do it, next step I think is to update the patch with the SloppyPhraseQuery approximation). omitPositions improvements -- Key: SOLR-2660 URL: https://issues.apache.org/jira/browse/SOLR-2660 Project: Solr Issue Type: Improvement Affects Versions: 3.3, 4.0 Reporter: Robert Muir Priority: Minor Attachments: SOLR-2660.patch followup to LUCENE-2048: Adds factory methods getPhraseQuery/getMultiPhraseQuery to QP, this way you can subclass it and customize behavior, particularly * by default, Solr throws exception here if the fieldtype omits positions: rather than 3.x's silent failure of no results, and even for trunk its nicer to fail during query parsing rather than waiting for lucene's failure during execution. * adds phraseAsBoolean, which allows you to downgrade these phrase/multiphrase queries to boolean queries: this is a nice option in conjunction with our word n-gram filters (shingle/commongrams/etc)for a fast approximation, if your application can tolerate some false positives, e.g. foo bar - termQuery(foo_bar), foo bar baz - BQ(foo_bar AND bar_baz) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Indexing Boolean Expressions
I looked at LUCENE-2987 and its work on the query side (changes to the accepted syntax to accept lower case 'or' and 'and'), which isn't really related to my proposal. What I'm proposing is to be able to index complex boolean expressions using Lucene. This can be viewed as the opposite of the regular search task. The objective here is find a set of relevant queries given a document (assignment of values to fields). This by itself may not sound that interesting but its a key piece to efficiently implementing any MATCHING system which is effectively a two-way search where constraints are defined both-ways. An example of this would be: 1) Job matching: Potential employers define their job posting as a documents along with complex boolean expressions used to narrow potential candidates. Job searchers upload their profile and may formulate complex queries when executing a search. Once a is search initiated from any of the sides constraints need to satisfied both ways. 2) Advertising: Publishers define constraints on the type of advertisers/ads they are willing to show in their sites. On the other hand, advertisers define constraints (typically at the campaign level) on publisher sites they want their ads to show at as well as on the user audiences they are targeting to. While some attribute values are known at definition time, others are only instantiated once the user visits a given page which triggers a matching request that must be satisfied in few milliseconds to select valid ads and then scored based on relevance. So in a matching system a MATCH QUERY is considered to to be a tuple that consists of a value assignment to attributes/fields (doc) + a boolean expression (query) that goes against a double index also built on tuples that simultaneously boolean expressions and associated documents. To do this efficiently we need to be able to build indexes on Boolean expressions (Lucene queries) and retrieve the set of matching expressions given a doc (typically few attributes with values assigned), which is the core of what is described in this paper: Indexing Boolean Expressions (See http://www.vldb.org/pvldb/2/vldb09-83.pdf) -- J So to effectively resolve the problem of realtime matching one can On Tue, Feb 21, 2012 at 2:18 PM, Joe Cabrera calcmaste...@gmail.com wrote: On 02/21/2012 12:15 PM, Aayush Kothari wrote: So if Aayush Kothari is interested in working on this as a Student, all we need is a formal mentor (I can be the informal one). Anyone up for the task? Completely interested in working for and learning about the aforementioned subject/project. +1. This may be related to the work I'm doing with LUCENE-2987 Basically changing the grammar to accepts conjunctions AND and OR in the query text. I would be interested in working with you on some of the details. However, I too am not a formal committer. -- Joe Cabreraeminorlabs.com
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222481#comment-13222481 ] Adam Estrada commented on LUCENE-3795: -- Yes...why not grow SIS seeing as its already in Apache Incubation? If another project is launched with the same intention as SIS, wouldn't that mean there is the potential for duplicate technologies sitting on an Apache server? There are a ton of different components to building out a proper geospatial core technology. GDAL/OGR, OpenLayers and the database storage techs therein represent some of the high points to operating a full GIS. See Wikipedia article (http://en.wikipedia.org/wiki/Geographic_information_system) and note that in order for there to be a full-fledged GIS, there has to be several mutually exclusive components that work in harmony with each other. I see Spatial4J being a great new way to implement geometric functions and storage within a Lucene index. That leaves the format/projection support, visualization and management components. Wouldn't it be nice to roll all of these fundamental concepts in to a single project like SIS? I am looking at the big picture rather than specific or individual components. w/r, Adam Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3850:
--
Attachment: LUCENE-3850-part2.patch
2nd part of checnges for trunk. Grouping module is unfixable without knowledge
on the generics. We should add rawtypes everywhere :-)
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3851) TestTermInfosReaderIndex failing (always reproducible)
TestTermInfosReaderIndex failing (always reproducible)
--
Key: LUCENE-3851
URL: https://issues.apache.org/jira/browse/LUCENE-3851
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 4.0
Always fails on branch (use reproduce string below):
git clone --depth 1 -b rr g...@github.com:dweiss/lucene_solr.git
{noformat}
[junit4] Running org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex
[junit4] FAILURE 0.04s J0 | TestTermInfosReaderIndex.testSeekEnum
[junit4] Throwable #1: java.lang.AssertionError:
expected:field9:z91ob3wozm6d but was::
[junit4] at
__randomizedtesting.SeedInfo.seed([C7597DFBBE0B3D7D:C6D9CEDD0700AAFF]:0)
[junit4] at org.junit.Assert.fail(Assert.java:93)
[junit4] at org.junit.Assert.failNotEquals(Assert.java:647)
[junit4] at org.junit.Assert.assertEquals(Assert.java:128)
[junit4] at org.junit.Assert.assertEquals(Assert.java:147)
[junit4] at
org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex.testSeekEnum(TestTermInfosReaderIndex.java:137)
[junit4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit4] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit4] at java.lang.reflect.Method.invoke(Method.java:597)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1766)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1000(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:728)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:789)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:803)
[junit4] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:744)
[junit4] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:636)
[junit4] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:550)
[junit4] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:735)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:586)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:605)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:641)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:652)
[junit4] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:533)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:479)
[junit4]
[junit4] 2 NOTE: reproduce with: ant test
-Dtests.filter=*.TestTermInfosReaderIndex -Dtests.filter.method=testSeekEnum
-Drt.seed=C7597DFBBE0B3D7D -Dargs=-Dfile.encoding=UTF-8
[junit4] 2
[junit4] (@AfterClass output)
[junit4] 2 NOTE: test params are: codec=Appending, sim=DefaultSimilarity,
locale=en, timezone=Atlantic/Stanley
[junit4] 2 NOTE: all tests run in this JVM:
[junit4] 2 [TestLock, TestFileSwitchDirectory, TestWildcardRandom,
TestVersionComparator, TestTermdocPerf, TestBitVector, TestParallelTermEnum,
TestSimpleSearchEquivalence, TestNumericRangeQuery64, TestSort, TestIsCurrent,
TestToken, TestIntBlockCodec, TestDocumentsWriterDeleteQueue, TestPagedBytes,
TestThreadedForceMerge, TestOmitTf, TestSegmentTermEnum, TestIndexWriterConfig,
TestCheckIndex, TestTermVectorsWriter, TestNumericTokenStream, TestSearchAfter,
TestRegexpQuery, InBeforeClass, InAfterClass, InTestMethod,
NonStringProperties, TestIndexWriterMergePolicy, TestVirtualMethod,
TestFieldCache, TestSurrogates, TestSegmentTermDocs,
TestMultiValuedNumericRangeQuery, TestBasicOperations, TestCodecs,
TestDateSort, TestPositiveScoresOnlyCollector,
[jira] [Commented] (LUCENE-3749) Similarity.java javadocs and simplifications for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222521#comment-13222521
]
Neil Hooey commented on LUCENE-3749:
Thanks Robert, I've got it working now. I just set my default similarity to
{{SchemaSimilarityFactory}} and it works just as it did before.
Similarity.java javadocs and simplifications for 4.0
Key: LUCENE-3749
URL: https://issues.apache.org/jira/browse/LUCENE-3749
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3749.patch, LUCENE-3749_part2.patch
As part of adding additional scoring systems to lucene, we made a lower-level
Similarity
and the existing stuff became e.g. TFIDFSimilarity which extends it.
However, I always feel bad about the complexity introduced here (though I do
feel there
are some excuses, that its a difficult challenge).
In order to try to mitigate this, we also exposed an easier API
(SimilarityBase) on top of
it that makes some assumptions (and trades off some performance) to try to
provide something
consumable for e.g. experiments.
Still, we can cleanup a few things with the low-level api: fix outdated
documentation and
shoot for better/clearer naming etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3821) SloppyPhraseScorer sometimes misses documents that ExactPhraseScorer finds.
[ https://issues.apache.org/jira/browse/LUCENE-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-3821: Attachment: LUCENE-3821.patch Attached updated patch. Repeating PPs with multi-Phrase-query is handled as well. This called for more cases in the sloppy phrase scorer and more code, and, although I think the code is cleaner now, I don't know to what extent is it easier to maintain. It definitely fixes wrong behavior that exists in current 3x and trunk (patch is for 3x). However, although the random test passes for me even with -Dtests.iter=2000, it is possible to break the scorer - that is, create a document and a query which should match each other but would not. The patch adds just such a case as an @Ignored test case: TestMultiPhraseQuery.testMultiSloppyWithRepeats(). I don't see how to solve this specific case in the context of current sloppy phrase scorer. So there are 3 options: # leave things as they are # commit this patch and for now document the failing scenario (also keep it in the ignored test case). # devise a different algorithm for this. I would love it to be the 3rd if I just knew how to do it. Otherwise I like the 2nd, just need to keep in mind that the random test might from time to time create this scenario and so there will be noise in the test builds. Preferences? SloppyPhraseScorer sometimes misses documents that ExactPhraseScorer finds. --- Key: LUCENE-3821 URL: https://issues.apache.org/jira/browse/LUCENE-3821 Project: Lucene - Java Issue Type: Bug Affects Versions: 3.5, 4.0 Reporter: Naomi Dushay Assignee: Doron Cohen Attachments: LUCENE-3821.patch, LUCENE-3821.patch, LUCENE-3821.patch, LUCENE-3821.patch, LUCENE-3821_test.patch, schema.xml, solrconfig-test.xml The general bug is a case where a phrase with no slop is found, but if you add slop its not. I committed a test today (TestSloppyPhraseQuery2) that actually triggers this case, jenkins just hasn't had enough time to chew on it. ant test -Dtestcase=TestSloppyPhraseQuery2 -Dtests.iter=100 is enough to make it fail on trunk or 3.x -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3850:
--
Attachment: LUCENE-3850-parts2-branch3x.patch
Part2 for branch3x. Will commit now.
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch,
LUCENE-3850-parts2-branch3x.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3850) Fix rawtypes warnings for Java 7 compiler
[
https://issues.apache.org/jira/browse/LUCENE-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222541#comment-13222541
]
Uwe Schindler commented on LUCENE-3850:
---
Committed 2nd patch trunk revision: 1297162
Committed 2nd patch 3.x revision: 1297189
Fix rawtypes warnings for Java 7 compiler
-
Key: LUCENE-3850
URL: https://issues.apache.org/jira/browse/LUCENE-3850
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5, 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 3.6, 4.0
Attachments: LUCENE-3850-part1-branch3x.patch,
LUCENE-3850-part1.patch, LUCENE-3850-part2.patch,
LUCENE-3850-parts2-branch3x.patch
Java 7 changed the warnings a little bit:
- Java 6 only knew unchecked warning type, applying for all types of
generics violations, like missing generics (raw types)
- Java 7 still knows unchecked but only emits warning if the call is really
unchecked. Declaration of variables/fields or constructing instances without
type param now emits rawtypes warning.
The changes above causes the Java 7 compile now emit lots of rawtypes
warnings, where Java 6 is silent. The easy fix is to suppres both warning
types: @SuppressWarnings({unchecked,rawtypes}) for all those places.
Changes are easy to do, will provide patch later!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1772) UpdateProcessor to prune empty values
[ https://issues.apache.org/jira/browse/SOLR-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1772. Resolution: Duplicate Fix Version/s: 4.0 Assignee: Hoss Man yep ... covered as part of SOLR-2802 UpdateProcessor to prune empty values --- Key: SOLR-1772 URL: https://issues.apache.org/jira/browse/SOLR-1772 Project: Solr Issue Type: Wish Reporter: Hoss Man Assignee: Hoss Man Fix For: 4.0 Users seem to frequently get confused when some FieldTypes (typically the numeric ones) complain about invalid field values when the inadvertantly index an empty string. It would be cool to provide an UpdateProcessor that makes it easy to strip out any fields being added as empty values ... it could be configured using field (and/or field type) names or globs to select/ignore certain fields -- i haven't thought it through all that hard -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Data Streaming algorithms
I currently use Apache Lucene for analysis of text documents. However my new research involves the design of techniques and algorithms for data stream mining of social media. I do not think currently the Apache Lucene framework specifically contains support for streaming data. If Apache Lucene does not I may consider forking the current Lucene project and developing a new one better suited to data streams. Any thoughts for the developers on the current Apache Lucene project? -- Joe Cabrera eminorlabs.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222558#comment-13222558 ] Stefan Matheis (steffkes) commented on SOLR-3174: - Created another one for ryan's radical view: http://files.mathe.is/solr-admin/cloud-state/jit-rgraph/ - i've added another shard w/ three nodes, just for layout purposes .. otherwise the generated layout looks a [bit odd|http://files.mathe.is/solr-admin/cloud-state/jit-rgraph/index-2.html] ;o To continue w/ the integration of that view, it would be very helpful to get some real life data .. would that be possible? what would a cluster normally look like? how many shards w/ how many nodes? so i'd get a feeling on how large the Graphs could be .. where they could be integrated in the admin-ui and so on :) Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222578#comment-13222578 ] Ryan McKinley commented on LUCENE-3795: --- bq. Wouldn't it be nice to roll all of these fundamental concepts in to a single project like SIS? I agree -- but the elephant in the room is the LGPL library JTS. From previous discussions, I believe this was a non-starter for their compile/test environment, but I have emailed the sis-dev@ list to see if this is still their feeling. With spatial4j, we want a solid ASL solution, but also support complex polygons if people choose to use JTS in their runtime environment. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3202) Remove JSP from solr webapp
Remove JSP from solr webapp --- Key: SOLR-3202 URL: https://issues.apache.org/jira/browse/SOLR-3202 Project: Solr Issue Type: Task Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 The 4.0 admin UI does not use JSP to create its interface (It uses javascript and RequestHandlers) We only use JSP to fill in the path to the core in index.jsp -- this can be replaced with simple template text -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3851) TestTermInfosReaderIndex failing (always reproducible)
[
https://issues.apache.org/jira/browse/LUCENE-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222586#comment-13222586
]
Robert Muir commented on LUCENE-3851:
-
Thanks Dawid: i'll take a look at this first chance i get (unless Mike beats me
to it).
This looks scary: we've had bugs with 3.x's terms dict around
emptyField+emptyTerm before. I hope its just a test bug.
TestTermInfosReaderIndex failing (always reproducible)
--
Key: LUCENE-3851
URL: https://issues.apache.org/jira/browse/LUCENE-3851
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 4.0
Always fails on branch (use reproduce string below):
git clone --depth 1 -b rr g...@github.com:dweiss/lucene_solr.git
{noformat}
[junit4] Running org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex
[junit4] FAILURE 0.04s J0 | TestTermInfosReaderIndex.testSeekEnum
[junit4] Throwable #1: java.lang.AssertionError:
expected:field9:z91ob3wozm6d but was::
[junit4] at
__randomizedtesting.SeedInfo.seed([C7597DFBBE0B3D7D:C6D9CEDD0700AAFF]:0)
[junit4] at org.junit.Assert.fail(Assert.java:93)
[junit4] at org.junit.Assert.failNotEquals(Assert.java:647)
[junit4] at org.junit.Assert.assertEquals(Assert.java:128)
[junit4] at org.junit.Assert.assertEquals(Assert.java:147)
[junit4] at
org.apache.lucene.codecs.lucene3x.TestTermInfosReaderIndex.testSeekEnum(TestTermInfosReaderIndex.java:137)
[junit4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit4] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit4] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit4] at java.lang.reflect.Method.invoke(Method.java:597)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1766)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1000(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:728)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:789)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:803)
[junit4] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:744)
[junit4] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:636)
[junit4] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:550)
[junit4] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:735)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:586)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:605)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:641)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:652)
[junit4] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:533)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:141)
[junit4] at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:479)
[junit4]
[junit4] 2 NOTE: reproduce with: ant test
-Dtests.filter=*.TestTermInfosReaderIndex -Dtests.filter.method=testSeekEnum
-Drt.seed=C7597DFBBE0B3D7D -Dargs=-Dfile.encoding=UTF-8
[junit4] 2
[junit4] (@AfterClass output)
[junit4] 2 NOTE: test params are: codec=Appending, sim=DefaultSimilarity,
locale=en, timezone=Atlantic/Stanley
[junit4] 2 NOTE: all tests run in this JVM:
[junit4] 2 [TestLock, TestFileSwitchDirectory,
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222599#comment-13222599 ] Erick Erickson commented on SOLR-3174: -- Way cool! I suspect that we should give them all the space they can have, but plan for 5 shards, three replicas? That covers quite a large installation actually. Almost immediately someone will have 20 shards and 10 replicas each, but at some point it gets ridiculous. How about opening up a new tab and giving them the whole screen? As you can tell, there's a dearth of real life data here, all we can do is guess. Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3203) SolrCloud should demand that the schema has the _version_ field
SolrCloud should demand that the schema has the _version_ field Key: SOLR-3203 URL: https://issues.apache.org/jira/browse/SOLR-3203 Project: Solr Issue Type: Improvement Reporter: Lance Norskog SolrCloud does not function correctly without the _version_ field. It should fail at startup if this is not in the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3203) SolrCloud should demand that the schema has the _version_ field
[ https://issues.apache.org/jira/browse/SOLR-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog updated SOLR-3203: Component/s: SolrCloud Fix Version/s: 4.0 Priority: Minor (was: Major) SolrCloud should demand that the schema has the _version_ field Key: SOLR-3203 URL: https://issues.apache.org/jira/browse/SOLR-3203 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Lance Norskog Priority: Minor Fix For: 4.0 SolrCloud does not function correctly without the _version_ field. It should fail at startup if this is not in the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222620#comment-13222620 ] Mark Miller commented on SOLR-3174: --- I would guestimate common distributed setups might have 3-15 shards (favoring lower). Common replication factor might be 2 or 3. Of course those with billions of docs collections might get into 100+ shards area - again replication factor is still going to probably be 3-5 max I would guess. Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222637#comment-13222637 ] Cody Young commented on SOLR-3174: -- 18 shards, 3-5 replicas here. Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222729#comment-13222729 ] Ryan McKinley commented on LUCENE-3795: --- I have confirmed with SIS that a compile/test dependency on JTS in not possible. (One of their main goals is to make an ASL version of JTS... A great goal, but they are not yet to 1st base) So, where does that leave us? Is the spatial4j.jar a blocker for anyone? I understand it is not everyone's preferred option -- but no option makes everyone happy. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3202) Remove JSP from solr webapp
[
https://issues.apache.org/jira/browse/SOLR-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-3202:
Attachment: SOLR-3202-no-jsp.patch
This loads the admin UI with a simple servlet and:
{code:java}
+ String[] search = new String[] {
+ ${contextPath},
+ ${adminPath}
+ };
+ String[] replace = new String[] {
+ request.getContextPath(),
+ cores.getAdminPath()
+ };
+
+ out.println( StringUtils.replaceEach(html, search, replace) );
{code}
Remove JSP from solr webapp
---
Key: SOLR-3202
URL: https://issues.apache.org/jira/browse/SOLR-3202
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 4.0
Attachments: SOLR-3202-no-jsp.patch
The 4.0 admin UI does not use JSP to create its interface (It uses javascript
and RequestHandlers)
We only use JSP to fill in the path to the core in index.jsp -- this can be
replaced with simple template text
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[
https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222739#comment-13222739
]
Chris A. Mattmann commented on LUCENE-3795:
---
I'd encourage folks to read:
http://markmail.org/message/75yrfmumxlmdgxzz
and all of the surrounding discussion there.
Quoting Greg Stein:
{quote}
I simply think that it is a mistake for a PMC to create any sort of dependency
upon code that is more restrictive than the Apache License. In this case, it
means somebody must grab LGPL code in order to build our provided tarball. I
would strongly advise against such a build dependency, whether the runtime
requires it or not.
{quote}
I strongly agree with his interpretation.
Replace spatial contrib module with LSP's spatial-lucene module
---
Key: LUCENE-3795
URL: https://issues.apache.org/jira/browse/LUCENE-3795
Project: Lucene - Java
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0
I propose that Lucene's spatial contrib module be replaced with the
spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been
in development for approximately 1 year by David Smiley, Ryan McKinley, and
Chris Male and we feel it is ready. LSP is here:
http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene
module is intuitively in svn/trunk/spatial-lucene/.
I'll add more comments to prevent the issue description from being too long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3202) Remove JSP from solr webapp
[
https://issues.apache.org/jira/browse/SOLR-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222759#comment-13222759
]
Uwe Schindler commented on SOLR-3202:
-
+1
Except:
{noformat}
+ String html = IOUtils.toString(new FileReader(f));
{noformat}
Thats a bad idea as it uses default charset. Use IOUtils.toString(new
FileInputStream(f), UTF-8) or like that. Of course it must also set the
content-type correctly, including charset before getting the reader.
Remove JSP from solr webapp
---
Key: SOLR-3202
URL: https://issues.apache.org/jira/browse/SOLR-3202
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 4.0
Attachments: SOLR-3202-no-jsp.patch
The 4.0 admin UI does not use JSP to create its interface (It uses javascript
and RequestHandlers)
We only use JSP to fill in the path to the core in index.jsp -- this can be
replaced with simple template text
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222781#comment-13222781 ] Ryan McKinley commented on LUCENE-3795: --- bq. PMC to create any sort of dependency upon code that is more restrictive than the Apache License. Note, the spatial4j.jar file is ASL No user ever needs to touch LGPL code or artifacts Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3197) Allow firstSearcher and newSearcher listeners to run in multiple threads
[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222790#comment-13222790
]
Neil Hooey commented on SOLR-3197:
--
{quote}
The original rational was do we really want to peg more than one CPU with
warmup while we are still serving live traffic?
But some people are using pretty big boxes these days.
{quote}
When Solr is configured _not_ to serve queries while warming, would it make
sense to use as many CPUs as possible, since it's probably not doing anything
else?
Allow firstSearcher and newSearcher listeners to run in multiple threads
Key: SOLR-3197
URL: https://issues.apache.org/jira/browse/SOLR-3197
Project: Solr
Issue Type: Improvement
Reporter: Lance Norskog
SolrCore submits all listeners (firstSearcher and newSearcher) to a java
ExecutorService, but uses a single-threaded one.
line 965 in the trunk:
{code}
SolrCore.java around line 965: final ExecutorService searcherExecutor =
Executors.newSingleThreadExecutor();
line 1280 in the trunk:
SolrCore.java around line 1280 runs first the, and then the first and new
searchers, all with the searcherExecutor object created at line 965.
Would it work if we changed this ExecutorService to a thread pool version?
This seems like it should work:
{code}
java.util.concurrent.Executors.newFixedThreadPool(int nThreads, ThreadFactory
threadFactory);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2667) Finish Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-2667: Component/s: web gui Finish Solr Admin UI Key: SOLR-2667 URL: https://issues.apache.org/jira/browse/SOLR-2667 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-2667-110722.patch, SOLR-2667-120223-file-structure.patch In SOLR-2399, we added a new admin UI. The issue has gotten too long to follow, so this is a new issue to track remaining tasks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3162: Component/s: web gui Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis, web gui Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3174: Component/s: web gui Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2635) FieldAnalysisRequestHandler; Expose Filter- Tokenizer-Settings
[ https://issues.apache.org/jira/browse/SOLR-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-2635. - Resolution: Fixed Fix Version/s: 4.0 I think this was fixed a while back FieldAnalysisRequestHandler; Expose Filter- Tokenizer-Settings Key: SOLR-2635 URL: https://issues.apache.org/jira/browse/SOLR-2635 Project: Solr Issue Type: Improvement Components: Schema and Analysis, web gui Reporter: Stefan Matheis (steffkes) Assignee: Uwe Schindler Priority: Minor Fix For: 4.0 The [current/old Analysis Page|http://files.mathe.is/solr-admin/04_analysis_verbose_cur.png] exposes the Filter- Tokenizer-Settings -- the FieldAnalysisRequestHandler not :/ This Information is already available on the [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png] (through LukeRequestHandler) - so we could load this in parallel and grab the required informations .. but it would be easier if we could add this Information, so that we have all relevant Information at one Place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3181) New Admin UI, allow user to somehow cut/paste all the old Zookeeper info.
[ https://issues.apache.org/jira/browse/SOLR-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3181: Component/s: web gui New Admin UI, allow user to somehow cut/paste all the old Zookeeper info. --- Key: SOLR-3181 URL: https://issues.apache.org/jira/browse/SOLR-3181 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Environment: n/a Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor Attachments: SOLR-3181.patch When tracking down issues with ZK, the devs ask about various bits of data from the cloud pages. It would be convenient to be able to just capture all the data from the old /solr/admin/zookeeper.jsp page in the admin interface to be able to send it to anyone debugging the info. Perhaps just a get debug info for Apache. Or even more cool copy debug info to clipboard if that's possible. Is this just the raw data that the cloud view is manipulating? It doesn't have to be pretty although indentation would be nice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3188) New admin page: Enable Polling button disappears after disabling polling and reloading page
[ https://issues.apache.org/jira/browse/SOLR-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3188: Component/s: (was: Schema and Analysis) web gui New admin page: Enable Polling button disappears after disabling polling and reloading page - Key: SOLR-3188 URL: https://issues.apache.org/jira/browse/SOLR-3188 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Neil Hooey Priority: Minor Labels: admin When you go to this URL on a slave: http://localhost:8983/solr/#/singlecore/replication And click the Disable Polling button, you see a red bar that says invalid_master. I'm not sure why I get this red bar, as I haven't tested it outside of my own installation, but it seems normal. If you then refresh the page, the Replicate Now and Enable Polling buttons disappear. It seems like their generation is being interrupted by the invalid_master error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3205) Better error reporting from Analysis UI
Better error reporting from Analysis UI
---
Key: SOLR-3205
URL: https://issues.apache.org/jira/browse/SOLR-3205
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Ryan McKinley
Fix For: 4.0
The new analysis UI does not behave well with invalid input. To reproduce,
from /#/singlecore/analysis
* Select a number field (int)
* put in invalid text (hello)
* click Analyse Values
The UI will have a red banner, but not say anything useful. The log file will
say:
{code}
SEVERE: org.apache.solr.common.SolrException: Invalid Number: hello
at
org.apache.solr.analysis.TrieTokenizer.reset(TrieTokenizerFactory.java:113)
at
org.apache.solr.analysis.TrieTokenizer.init(TrieTokenizerFactory.java:76)
{code}
Hopefully we can get the UI to say Invalid Number: hello
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-67) query interface with faceted browsing, highligting
[ https://issues.apache.org/jira/browse/SOLR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-67. --- Resolution: Fixed I think this is resolved in SOLR-2178 query interface with faceted browsing, highligting -- Key: SOLR-67 URL: https://issues.apache.org/jira/browse/SOLR-67 Project: Solr Issue Type: Wish Components: web gui Reporter: Yonik Seeley It would be nice to a nice HTML page allowing the user to query and display 1) some faceting info such as hit counts with links that allowed the user to narrow their search results. 2) highlighted summaries 3) easy way to query the dismax handler as well as the standard request handler Most likely this would be built into the admin pages (and have access to all the field info). It would also seem useful to have an advanced query page... something like http://www.nabble.com/forum/AdvSearch.jtp or http://www.google.com/advanced_search?hl=en that would allow one to easily customize and drop into their site. This might be best as contrib module run outside of Solr (a JSP, etc?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3202) Remove JSP from solr webapp
[ https://issues.apache.org/jira/browse/SOLR-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3202: Attachment: SOLR-3202-no-jsp.patch This is a more complete patch that actually removes the JSP files and dependencies Remove JSP from solr webapp --- Key: SOLR-3202 URL: https://issues.apache.org/jira/browse/SOLR-3202 Project: Solr Issue Type: Task Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3202-no-jsp.patch, SOLR-3202-no-jsp.patch The 4.0 admin UI does not use JSP to create its interface (It uses javascript and RequestHandlers) We only use JSP to fill in the path to the core in index.jsp -- this can be replaced with simple template text -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Remove old Solr UI from /trunk?
Are we ready to remove the old UI from trunk? I would like to move forward with SOLR-3202 (removing JSP) I believe the Log level selection stuff is the only feature not supported by the new UI (yet) -- anything else? ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222911#comment-13222911 ] Ryan McKinley commented on SOLR-3204: - Solr is using a snapshot commons CSV build (commons-csv-1.0-SNAPSHOT-r966014) -- solr does not change anything and would prefer to use a release build. Has there been class refactorings that make replacing the .jar with the dev build impossible? If so, perhaps we should just update the .jar file we are including. solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3206) FST package API refactoring
[ https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222910#comment-13222910 ] Robert Muir commented on LUCENE-3206: - 3.6 pruning: can we push this out to 4.0? FST package API refactoring --- Key: LUCENE-3206 URL: https://issues.apache.org/jira/browse/LUCENE-3206 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Affects Versions: 3.2 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3206.patch The current API is still marked @experimental, so I think there's still time to fiddle with it. I've been using the current API for some time and I do have some ideas for improvement. This is a placeholder for these -- I'll post a patch once I have a working proof of concept. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2921) Now that we track the code version at the segment level, we can stop tracking it also in each file level
[ https://issues.apache.org/jira/browse/LUCENE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222912#comment-13222912 ] Robert Muir commented on LUCENE-2921: - 3.6 pruning: can we push this out to 4.0? Now that we track the code version at the segment level, we can stop tracking it also in each file level Key: LUCENE-2921 URL: https://issues.apache.org/jira/browse/LUCENE-2921 Project: Lucene - Java Issue Type: Improvement Components: core/index Reporter: Shai Erera Fix For: 3.6, 4.0 Now that we track the code version that created the segment at the segment level, we can stop tracking versions in each file. This has several major benefits: # Today the constant names that use to track versions are confusing - they do not state since which version it applies to, and so it's harder to determine which formats we can stop supporting when working on the next major release. # Those format numbers are usually negative, but in some cases positive (inconsistency) -- we need to remember to increase it one down for the negative ones, which I always find confusing. # It will remove the format tracking from all the *Writers, and the *Reader will receive the code format (String) and work w/ the appropriate constant (e.g. Constants.LUCENE_30). Centralizing version tracking to SegmentInfo is an advantage IMO. It's not urgent that we do it for 3.1 (though it requires an index format change), because starting from 3.1 all segments track their version number anyway (or migrated to track it), so we can safely release it in follow-on 3x release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3003) Move UnInvertedField into Lucene core
[ https://issues.apache.org/jira/browse/LUCENE-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222914#comment-13222914 ] Robert Muir commented on LUCENE-3003: - 3.6 pruning: can we push this out to 4.0 (mark resolved?) Move UnInvertedField into Lucene core - Key: LUCENE-3003 URL: https://issues.apache.org/jira/browse/LUCENE-3003 Project: Lucene - Java Issue Type: Improvement Components: core/index Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3003.patch, LUCENE-3003.patch, byte_size_32-bit-openjdk6.txt Solr's UnInvertedField lets you quickly lookup all terms ords for a given doc/field. Like, FieldCache, it inverts the index to produce this, and creates a RAM-resident data structure holding the bits; but, unlike FieldCache, it can handle multiple values per doc, and, it does not hold the term bytes in RAM. Rather, it holds only term ords, and then uses TermsEnum to resolve ord - term. This is great eg for faceting, where you want to use int ords for all of your counting, and then only at the end you need to resolve the top N ords to their text. I think this is a useful core functionality, and we should move most of it into Lucene's core. It's a good complement to FieldCache. For this first baby step, I just move it into core and refactor Solr's usage of it. After this, as separate issues, I think there are some things we could explore/improve: * The first-pass that allocates lots of tiny byte[] looks like it could be inefficient. Maybe we could use the byte slices from the indexer for this... * We can improve the RAM efficiency of the TermIndex: if the codec supports ords, and we are operating on one segment, we should just use it. If not, we can use a more RAM-efficient data structure, eg an FST mapping to the ord. * We may be able to improve on the main byte[] representation by using packed ints instead of delta-vInt? * Eventually we should fold this ability into docvalues, ie we'd write the byte[] image at indexing time, and then loading would be fast, instead of uninverting -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3138) IW.addIndexes should fail fast if an index is too old/new
[ https://issues.apache.org/jira/browse/LUCENE-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222918#comment-13222918 ] Robert Muir commented on LUCENE-3138: - 3.6 pruning: can we push this out to 4.0? IW.addIndexes should fail fast if an index is too old/new - Key: LUCENE-3138 URL: https://issues.apache.org/jira/browse/LUCENE-3138 Project: Lucene - Java Issue Type: Improvement Components: core/index Reporter: Shai Erera Priority: Minor Fix For: 3.6, 4.0 Today IW.addIndexes (both Dir and IR versions) do not check the format of the incoming indexes. Therefore it could add a too old/new index and the app will discover that only later, maybe during commit() or segment merges. We should check that up front and fail fast. This issue is relevant only to 4.0 at the moment, which will not support 2.x indexes anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222917#comment-13222917 ] Yonik Seeley commented on SOLR-3204: Background here: http://markmail.org/message/lsxtxoetpw7a47uf As far as I can determine, this is just a maven meta-data issue? i.e. it doesn't seem like we should change java package names, but just make sure that the maven meta-data is completely distinct from any official commons-csv releases? (disclaimer: I still really know nothing of maven, other than it's becoming more a pain all the time ;-) solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222930#comment-13222930
]
Ryan McKinley commented on SOLR-3204:
-
Emmanuel, can you confirm this is just a maven issue?
Can it be solved with adding exclusions?
{code:xml}
dependency
groupIdorg.apache.solr/groupId
artifactIdsolr-core/artifactId
version${solr.version}/version
exclusions
exclusion
groupIdorg.apache.solr/groupId
artifactIdsolr-commons-csv/artifactId
/exclusion
...
{code}
Obviously the best approach is to work with an official release... but until
that exists, what do you suggest? (Actually forking the project and changing
the package names seems pretty bad)
solr-commons-csv must not use the org.apache.commons.csv package
Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6
The solr-commons-csv artifact reused the code from the Apache Commons CSV
project but the package wasn't changed to something else than
org.apache.commons.csv in the process. This creates a compatibility issue as
the Apache Commons team works toward an official release of Commons CSV. It
prevents Commons CSV from using its own org.apache.commons.csv package, or
forces the renaming of all the classes to avoid a classpath conflict.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3116) pendingCommit in IndexWriter is not thoroughly tested
[
https://issues.apache.org/jira/browse/LUCENE-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222933#comment-13222933
]
Robert Muir commented on LUCENE-3116:
-
its easy to add the sleep, but we dont even have good multithreaded tests with
rollback() [except testing how exceptions are handled and not really asserting
anything?]
Can we push this out to 4.0?
pendingCommit in IndexWriter is not thoroughly tested
-
Key: LUCENE-3116
URL: https://issues.apache.org/jira/browse/LUCENE-3116
Project: Lucene - Java
Issue Type: Test
Components: core/index
Affects Versions: 3.2, 4.0
Reporter: Uwe Schindler
Fix For: 3.6, 4.0
When working on LUCENE-3084, I had a copy-paste error in my patch (see
revision 1124307 and corrected in 1124316), I replaced pendingCommit by
segmentInfos in IndexWriter, corrected by the following patch:
{noformat}
--- lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java
(original)
+++ lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java
Wed May 18 16:16:29 2011
@@ -2552,7 +2552,7 @@ public class IndexWriter implements Clos
lastCommitChangeCount = pendingCommitChangeCount;
segmentInfos.updateGeneration(pendingCommit);
segmentInfos.setUserData(pendingCommit.getUserData());
-rollbackSegments = segmentInfos.createBackupSegmentInfos(true);
+rollbackSegments = pendingCommit.createBackupSegmentInfos(true);
deleter.checkpoint(pendingCommit, true);
} finally {
// Matches the incRef done in startCommit:
{noformat}
This did not cause any test failure.
On IRC, Mike said:
{quote}
[19:21] mikemccand: ThetaPh1: hmm
[19:21] mikemccand: well
[19:22] mikemccand: pendingCommit and sis only differ while commit() is
running
[19:22] mikemccand: ie if a thread starts commit
[19:22] mikemccand: but fsync is taking a long time
[19:22] mikemccand: and another thread makes a change to sis
[19:22] ThetaPh1: ok so hard to find that bug
[19:22] mikemccand: we need our mock dir wrapper to sometimes take a
long time syncing
{quote}
Maybe we need such a test, I feel bad when such stupid changes don't make any
test fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3844) Deprecate Token class and remove in trunk
[ https://issues.apache.org/jira/browse/LUCENE-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222938#comment-13222938 ] Robert Muir commented on LUCENE-3844: - How much work is this? I think even removing would be difficult. Maybe we should push deprecating this out to 4.0, giving us a lot of time to clean things up before its totally removed. Deprecate Token class and remove in trunk - Key: LUCENE-3844 URL: https://issues.apache.org/jira/browse/LUCENE-3844 Project: Lucene - Java Issue Type: Task Components: core/other, modules/analysis Affects Versions: 3.5 Reporter: Uwe Schindler Fix For: 3.6, 4.0 After issues like LUCENE-3843, introducing new attributes, we should remove Token class in trunk, as it leads to code that ignores those new attributes (like PositionLengthAttribute, ScriptAttribute, KeywordAttribute,...). If you want a holder for all Attributes a TokenStream, use TS.cloneAttributes(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3161) consider warnings from the source compilation
[ https://issues.apache.org/jira/browse/LUCENE-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3161: Fix Version/s: (was: 3.6) consider warnings from the source compilation - Key: LUCENE-3161 URL: https://issues.apache.org/jira/browse/LUCENE-3161 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Labels: maybe32blocker Fix For: 4.0 as Doron mentioned in his review: At compiling there are various warning printed, I think it would be more assuring for downloaders if the build runs without warning. These warnings are not a stopper. we could conditionalize these warnings so that they don't display when compiling from actual releases, but I have to wonder if we should hide these... being open source I think we should display all our warts, maybe some contributor sees these warnings and decides they want to submit a patch to fix some of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3755) Add examples to javadocs of Analyzer (4.0)/ReusableAnalyzerBase(3.6)
[
https://issues.apache.org/jira/browse/LUCENE-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3755:
Fix Version/s: (was: 3.6)
Add examples to javadocs of Analyzer (4.0)/ReusableAnalyzerBase(3.6)
Key: LUCENE-3755
URL: https://issues.apache.org/jira/browse/LUCENE-3755
Project: Lucene - Java
Issue Type: Task
Components: general/javadocs
Reporter: Robert Muir
Labels: newdev
Fix For: 4.0
This stuff is great, it makes it easy to define analyzers:
{code}
Analyzer analyzer = new Analyzer() {
@Override
protected TokenStreamComponents createComponents(String fieldName, Reader
reader) {
Tokenizer source = new FooTokenizer(reader);
TokenStream filter = new FooFilter(source);
filter = new BarFilter(filter);
return new TokenStreamComponents(source, filter);
}
};
{code}
But, we should add basic examples to the javadocs I think (we can backport to
ReusableAnalyzerBase).
Also it would be nice to throw in an example that adds a CharFilter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2974) the hudson nightly for lucene should check out lucene by itself
[ https://issues.apache.org/jira/browse/LUCENE-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-2974: Fix Version/s: (was: 3.6) the hudson nightly for lucene should check out lucene by itself --- Key: LUCENE-2974 URL: https://issues.apache.org/jira/browse/LUCENE-2974 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 4.0 Currently its too easy to break the lucene-only packaging and build. the hudson job for lucene should check out lucene by itself, this will prevent it from being broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
