[jira] [Created] (SOLR-4506) [solr4.0.0] many index.{date} dir in replication node
zhuojunjian created SOLR-4506:
-
Summary: [solr4.0.0] many index.{date} dir in replication node
Key: SOLR-4506
URL: https://issues.apache.org/jira/browse/SOLR-4506
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: the solr4.0 runs on suse11.
mem:32G
cpu:16 cores
Reporter: zhuojunjian
Fix For: 4.0
in our test,we used solrcloud feature in solr4.0(version detail
:4.0.0.2012.10.06.03.04.33).
the solrcloud configuration is 3 shards and 2 replications each shard.
we found that there are over than 25 dirs which named index.{date} in one
replication node belonging to shard 3.
for example:
index.2013021725864 index.20130218012211880 index.20130218015714713
index.20130218023101958 index.20130218030424083 tlog
index.20130218005648324 index.20130218012751078 index.20130218020141293
the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0.
so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ?
what can I do?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1781) Replication index directories not always cleaned up
[ https://issues.apache.org/jira/browse/SOLR-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586918#comment-13586918 ] zhuojunjian commented on SOLR-1781: --- hi sure this issue is fixed in solr4.0 ? we find the issue in solr4.0 in our enviroment . I have created a new JIRA SOLR-4506. Replication index directories not always cleaned up --- Key: SOLR-1781 URL: https://issues.apache.org/jira/browse/SOLR-1781 Project: Solr Issue Type: Bug Components: replication (java), SolrCloud Affects Versions: 1.4 Environment: Windows Server 2003 R2, Java 6b18 Reporter: Terje Sten Bjerkseth Assignee: Mark Miller Fix For: 4.0-BETA, 5.0 Attachments: 0001-Replication-does-not-always-clean-up-old-directories.patch, SOLR-1781.patch, SOLR-1781.patch We had the same problem as someone described in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201001.mbox/%3c222a518d-ddf5-4fc8-a02a-74d4f232b...@snooth.com%3e. A partial copy of that message: We're using the new replication and it's working pretty well. There's one detail I'd like to get some more information about. As the replication works, it creates versions of the index in the data directory. Originally we had index/, but now there are dated versions such as index.20100127044500/, which are the replicated versions. Each copy is sized in the vicinity of 65G. With our current hard drive it's fine to have two around, but 3 gets a little dicey. Sometimes we're finding that the replication doesn't always clean up after itself. I would like to understand this better, or to not have this happen. It could be a configuration issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
Feature request - fq and boost function for MLT
Hi solar folks Looking at the current MLT implementation of solr, it gives good results but there is no way of specifying boost function for it like we can for search query. Currently at Bloomreach, we are using solr MLT for showing products related to a given page and it works great, but we wanted to do more with it like: 1. Filter out results that are out of stock 2. Give low boost to products which have 0 price 3. Use geodistance filter in the MLT results - documents farther away from the main product should score lower Considering these and more use cases in mind, i have generated a quick patch which touches MoreLikeThisComponent and MoreLikeThisHelper to provide this functionality with the following 2 params: *mlt.qf* and *mlt.multboost* . I would like to commit this patch if possible. What do you guys think? Thanks Gagan mlt-fq.patch Description: Binary data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4799) Enable extraction of originating term for ICU collation keys
Toke Eskildsen created LUCENE-4799: -- Summary: Enable extraction of originating term for ICU collation keys Key: LUCENE-4799 URL: https://issues.apache.org/jira/browse/LUCENE-4799 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1 Reporter: Toke Eskildsen Priority: Minor By concatenating generated ICU collation keys bytes with the originating term, it is possible to extract the originating term at a later time. This makes it possible to build a collator sorted facet field and similar multi-value/document structures. ICU collation keys are guaranteed to be terminated by a 0 (https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html) and since comparison of keys stop when a 0 is encountered, the addition of the originating term does not affect sort order. As 0 are _only_ used for termination in the key bytes, the extraction of the originating term is unambiguous. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4799) Enable extraction of originating term for ICU collation keys
[ https://issues.apache.org/jira/browse/LUCENE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated LUCENE-4799: --- Attachment: LUCENE-4799.patch Patch that enables originating term concatenation for ICUCollatedTermAttributeImpl and related classes. The unit-test is ugly and should probably be re-written. Enable extraction of originating term for ICU collation keys Key: LUCENE-4799 URL: https://issues.apache.org/jira/browse/LUCENE-4799 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1 Reporter: Toke Eskildsen Priority: Minor Labels: collator, facet Attachments: LUCENE-4799.patch By concatenating generated ICU collation keys bytes with the originating term, it is possible to extract the originating term at a later time. This makes it possible to build a collator sorted facet field and similar multi-value/document structures. ICU collation keys are guaranteed to be terminated by a 0 (https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html) and since comparison of keys stop when a 0 is encountered, the addition of the originating term does not affect sort order. As 0 are _only_ used for termination in the key bytes, the extraction of the originating term is unambiguous. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated LUCENE-4800:
--
Attachment: LUCENE-4800-trunk.patch
Patch implementing boolVal() in FloatDocValues. This fixes the problem but not
relying on type casting: (int)floatVal which rounds numbers down.
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] Lucene-trunk-Linux-Java7-64-test-only - Build # 25214 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/25214/
1 tests failed.
REGRESSION: org.apache.lucene.search.TestSameScoresWithThreads.test
Error Message:
MockDirectoryWrapper: cannot close: there are still open files: {_0.tvx=1,
_0.pos=1, _0.dvd=1, _0.tvd=1, _0.nvd=1, _0.tim=1, _0.tvf=1, _0.fdx=1, _0.doc=1,
_0.fdt=1}
Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still
open files: {_0.tvx=1, _0.pos=1, _0.dvd=1, _0.tvd=1, _0.nvd=1, _0.tim=1,
_0.tvf=1, _0.fdx=1, _0.doc=1, _0.fdt=1}
at
__randomizedtesting.SeedInfo.seed([3E926F8BCE0591B5:B6C6505160F9FC4D]:0)
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:585)
at
org.apache.lucene.search.TestSameScoresWithThreads.test(TestSameScoresWithThreads.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: unclosed IndexInput: _0.nvd
at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:476)
at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:518)
at
[jira] [Commented] (LUCENE-4799) Enable extraction of originating term for ICU collation keys
[ https://issues.apache.org/jira/browse/LUCENE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587037#comment-13587037 ] Robert Muir commented on LUCENE-4799: - I think maybe a separate field should be used. We discussed this before on the mailing list a while back and I mentioned my concerns. Enable extraction of originating term for ICU collation keys Key: LUCENE-4799 URL: https://issues.apache.org/jira/browse/LUCENE-4799 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1 Reporter: Toke Eskildsen Priority: Minor Labels: collator, facet Attachments: LUCENE-4799.patch By concatenating generated ICU collation keys bytes with the originating term, it is possible to extract the originating term at a later time. This makes it possible to build a collator sorted facet field and similar multi-value/document structures. ICU collation keys are guaranteed to be terminated by a 0 (https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html) and since comparison of keys stop when a 0 is encountered, the addition of the originating term does not affect sort order. As 0 are _only_ used for termination in the key bytes, the extraction of the originating term is unambiguous. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587047#comment-13587047
]
Robert Muir commented on LUCENE-4800:
-
Hmm I'm not sure about being able to cast a float as a boolean... can we make
it throw an exception if someone tries to do this instead?
(I get a parse exception trying to understand the example/use-case in the
description)
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 25214 - Failure!
test bug: i committed a fix
On Tue, Feb 26, 2013 at 6:01 AM, buil...@flonkings.com wrote:
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/25214/
1 tests failed.
REGRESSION: org.apache.lucene.search.TestSameScoresWithThreads.test
Error Message:
MockDirectoryWrapper: cannot close: there are still open files: {_0.tvx=1,
_0.pos=1, _0.dvd=1, _0.tvd=1, _0.nvd=1, _0.tim=1, _0.tvf=1, _0.fdx=1,
_0.doc=1, _0.fdt=1}
Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
still open files: {_0.tvx=1, _0.pos=1, _0.dvd=1, _0.tvd=1, _0.nvd=1,
_0.tim=1, _0.tvf=1, _0.fdx=1, _0.doc=1, _0.fdt=1}
at
__randomizedtesting.SeedInfo.seed([3E926F8BCE0591B5:B6C6505160F9FC4D]:0)
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:585)
at
org.apache.lucene.search.TestSameScoresWithThreads.test(TestSameScoresWithThreads.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: unclosed IndexInput: _0.nvd
at
[jira] [Commented] (LUCENE-4799) Enable extraction of originating term for ICU collation keys
[
https://issues.apache.org/jira/browse/LUCENE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587058#comment-13587058
]
Robert Muir commented on LUCENE-4799:
-
{quote}
and since comparison of keys stop when a 0 is encountered, the addition of the
originating term does not affect sort order.
{quote}
Thats what won't work here and will cause things to be screwy. This may work
with some comparison function written in the C programming language, but
doesn't hold here.
Enable extraction of originating term for ICU collation keys
Key: LUCENE-4799
URL: https://issues.apache.org/jira/browse/LUCENE-4799
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: 4.1
Reporter: Toke Eskildsen
Priority: Minor
Labels: collator, facet
Attachments: LUCENE-4799.patch
By concatenating generated ICU collation keys bytes with the originating
term, it is possible to extract the originating term at a later time. This
makes it possible to build a collator sorted facet field and similar
multi-value/document structures.
ICU collation keys are guaranteed to be terminated by a 0
(https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html)
and since comparison of keys stop when a 0 is encountered, the addition of
the originating term does not affect sort order. As 0 are _only_ used for
termination in the key bytes, the extraction of the originating term is
unambiguous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4799) Enable extraction of originating term for ICU collation keys
[ https://issues.apache.org/jira/browse/LUCENE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587061#comment-13587061 ] Toke Eskildsen commented on LUCENE-4799: I do not understand what you mean by separate field, Robert? The current patch does not touch Solr's ICUCollationField, but do you mean that Solr support should be added with a new field, such as ICUCollationExtendedField? Your primary concern, as I understand it, is that there is currently no clean way to perform analysis prior to collation key generation. Without a normalization step, we often end up with multiple keys that should have been the same, such as CD, Cd and cd. The patch is a first shot of originating term support and does not attempt to solve the missing pre-analysis for collation fields, which I find is a wholly separate issue. Enable extraction of originating term for ICU collation keys Key: LUCENE-4799 URL: https://issues.apache.org/jira/browse/LUCENE-4799 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1 Reporter: Toke Eskildsen Priority: Minor Labels: collator, facet Attachments: LUCENE-4799.patch By concatenating generated ICU collation keys bytes with the originating term, it is possible to extract the originating term at a later time. This makes it possible to build a collator sorted facet field and similar multi-value/document structures. ICU collation keys are guaranteed to be terminated by a 0 (https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html) and since comparison of keys stop when a 0 is encountered, the addition of the originating term does not affect sort order. As 0 are _only_ used for termination in the key bytes, the extraction of the originating term is unambiguous. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4799) Enable extraction of originating term for ICU collation keys
[ https://issues.apache.org/jira/browse/LUCENE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587067#comment-13587067 ] Toke Eskildsen commented on LUCENE-4799: Okay, I see how the order can be affected: If we have two terms that resolve to the same key, the extended version will result in two separate ByteRefs, while the plain version will result in only one. This is a problem if the field is used for sorting of documents and if there is a secondary sort criteria. Enable extraction of originating term for ICU collation keys Key: LUCENE-4799 URL: https://issues.apache.org/jira/browse/LUCENE-4799 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1 Reporter: Toke Eskildsen Priority: Minor Labels: collator, facet Attachments: LUCENE-4799.patch By concatenating generated ICU collation keys bytes with the originating term, it is possible to extract the originating term at a later time. This makes it possible to build a collator sorted facet field and similar multi-value/document structures. ICU collation keys are guaranteed to be terminated by a 0 (https://ssl.icu-project.org/apiref/icu4j48rc1/com/ibm/icu/text/CollationKey.html) and since comparison of keys stop when a 0 is encountered, the addition of the originating term does not affect sort order. As 0 are _only_ used for termination in the key bytes, the extraction of the originating term is unambiguous. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4505) Deadlock around SolrCoreState update lock.
[ https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587068#comment-13587068 ] Erick Erickson commented on SOLR-4505: -- I'm testing this now, it's been running for 5 minutes so all is well G. Actually, it's been taking a couple of hours to hit the race condition. I'll run it today in the background, and overnight tonight. If all goes well, I'll check it in tomorrow morning unless someone thinks it's a bad idea. Thanks a million! I'll assign this JIRA to myself just for bookeeping since I've got the stress test tool set up. Take it back if you want of course. Deadlock around SolrCoreState update lock. -- Key: SOLR-4505 URL: https://issues.apache.org/jira/browse/SOLR-4505 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.2, 5.0 Attachments: SOLR-4505.patch Erick found a deadlock with his core stress tool - see http://markmail.org/message/aq5hghbqia2uimgl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (SOLR-4505) Deadlock around SolrCoreState update lock.
[ https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-4505: Assignee: Erick Erickson (was: Mark Miller) Deadlock around SolrCoreState update lock. -- Key: SOLR-4505 URL: https://issues.apache.org/jira/browse/SOLR-4505 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Erick Erickson Priority: Minor Fix For: 4.2, 5.0 Attachments: SOLR-4505.patch Erick found a deadlock with his core stress tool - see http://markmail.org/message/aq5hghbqia2uimgl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587120#comment-13587120
]
Yonik Seeley commented on LUCENE-4800:
--
bq. Patch implementing boolVal() in FloatDocValues. This fixes the problem but
not relying on type casting: (int)floatVal which rounds numbers down.
Yeah, that makes sense, and matches the documentation for if.
For your specific case, the exists() function might be more straightforward:
if(exists($qq),1,0)
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587123#comment-13587123 ] Uwe Schindler commented on LUCENE-4798: --- The usage of SorterTemplate is correct. No bug in setPivot (it has to save the value not the index)! :-) PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587126#comment-13587126
]
Uwe Schindler commented on SOLR-4373:
-
The problem is in AnalysisSPILoader (not NamedSPILoader). The thread safetly
issue is not really the problem (it might be problem). The bug is in incorrect
copypasted code in AnalysisSPILoader: The reload() method throws away all
already loaded SPIs and starts with an empty list. I fixed it in LUCENE-4796.
Uwe
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587132#comment-13587132
]
Alexandre Rafalovitch commented on SOLR-4373:
-
I am trying to build the distribution to confirm, but - since it is my first
time - not sure what sequence of ant commands to run to get fully functioning
example directory with all the dist and contrib libraries in place.
**run-example** does not seem to generate the dist/contrib libraries and I am
not using subversion for **distrib** command.
Wiki seems to be silent on that as well. Is there a new developer guide
somewhere?
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587138#comment-13587138 ] Joel Bernstein commented on SOLR-4465: -- Sure, I'll take a look at the style guide and reformat the code. Thanks for the feedback. Configurable Collectors --- Key: SOLR-4465 URL: https://issues.apache.org/jira/browse/SOLR-4465 Project: Solr Issue Type: New Feature Components: search Affects Versions: 4.1 Reporter: Joel Bernstein Fix For: 4.2, 5.0 Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587147#comment-13587147 ] Michael McCandless commented on LUCENE-4798: +1, sneaky! PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587152#comment-13587152
]
Rene Nederhand commented on SOLR-4373:
--
You have to do an ant example in the solr directory.
Glad this problem seems to be solved. This bug already cost me a lot of
hours...
On Tue, Feb 26, 2013 at 2:58 PM, Alexandre Rafalovitch (JIRA)
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587159#comment-13587159
]
Alexandre Rafalovitch commented on SOLR-4373:
-
ant example does not build additional libraries in dist and contrib
directories. And that's what I am using for the test.
I guess I can change the path in the test to use pre-built libraries from
downloaded distribution, but would still be useful to know how to build the
whole lot.
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587162#comment-13587162
]
Rene Nederhand commented on SOLR-4373:
--
Sorry, I thought this would be clear from the readme. This is what I do (in
Linux):
svn co http://svn.apache.org/repos/asf/lucene/dev/trunk/
lucene-trunkcd lucene_trunk*# Apply patches (e.g. patch -p0
SOLR-3808-4.1-1.patch)*# It might be necessary to to a ant
ivy-bootstrap first# Based on ant 1.8.4
ant compilecd solr
ant example
ant dist
On Tue, Feb 26, 2013 at 3:24 PM, Alexandre Rafalovitch (JIRA)
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587166#comment-13587166
]
Robert Muir commented on LUCENE-4800:
-
the current patch will return 'true' for NaN
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
Andrew Schoen created LUCENE-4801: - Summary: Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
[ https://issues.apache.org/jira/browse/LUCENE-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schoen updated LUCENE-4801: -- Priority: Minor (was: Major) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity - Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen Priority: Minor Labels: documentation The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types
[ https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587182#comment-13587182 ] Mark Miller commented on SOLR-4503: --- I have not looked at the patch yet, but in general, I like restlet. It's dual licensed right? One of the licenses compat with Apache? Add REST API methods to get schema information: fields, dynamic fields, and field types --- Key: SOLR-4503 URL: https://issues.apache.org/jira/browse/SOLR-4503 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Affects Versions: 4.1 Reporter: Steve Rowe Assignee: Steve Rowe Attachments: SOLR-4503.patch Add REST methods that provide properties for fields, dynamic fields, and field types, using paths: /solr/(corename)/schema/fields /solr/(corename)/schema/fields/fieldname /solr/(corename)/schema/dynamicfields /solr/(corename)/schema/dynamicfields/pattern /solr/(corename)/schema/fieldtypes /solr/(corename)/schema/fieldtypes/typename -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_15) - Build # 4462 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4462/ Java: 64bit/jdk1.7.0_15 -XX:+UseG1GC All tests passed Build Log: [...truncated 26330 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.compressing... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene41... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene42... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_15 [javadoc] Building tree for all the packages and classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/package-summary.html... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Copying file /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png to directory /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/org/apache/lucene/search/doc-files... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning [...truncated 33 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis.ar... [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene.analysis.bg... [javadoc] Loading source files for package org.apache.lucene.analysis.br... [javadoc] Loading source files for package org.apache.lucene.analysis.ca... [javadoc] Loading source files for package org.apache.lucene.analysis.charfilter... [javadoc] Loading source files for package org.apache.lucene.analysis.cjk... [javadoc] Loading source files for package org.apache.lucene.analysis.cn... [javadoc] Loading source files for package org.apache.lucene.analysis.commongrams... [javadoc] Loading source files for package org.apache.lucene.analysis.compound... [javadoc] Loading source files for package org.apache.lucene.analysis.compound.hyphenation... [javadoc] Loading source files for package org.apache.lucene.analysis.core... [javadoc] Loading source files for package org.apache.lucene.analysis.cz... [javadoc] Loading source files for package org.apache.lucene.analysis.da... [javadoc] Loading source files for package org.apache.lucene.analysis.de... [javadoc] Loading source files for package org.apache.lucene.analysis.el... [javadoc] Loading source files for package org.apache.lucene.analysis.en... [javadoc] Loading source files for package org.apache.lucene.analysis.es... [javadoc] Loading source files for package org.apache.lucene.analysis.eu... [javadoc] Loading source files for package org.apache.lucene.analysis.fa... [javadoc] Loading source files for package org.apache.lucene.analysis.fi... [javadoc] Loading source files for package
[jira] [Commented] (LUCENE-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587185#comment-13587185 ] Commit Tag Bot commented on LUCENE-4798: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revisionrevision=1450206 LUCENE-4798: PostingsHighlighter's formatter sometimes doesnt highlight matched terms PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (LUCENE-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4798. - Resolution: Fixed Fix Version/s: 5.0 4.2 PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Fix For: 4.2, 5.0 Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4505) Deadlock around SolrCoreState update lock.
[ https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4505: - Attachment: newstack.txt No joy, here's the latest stack trace. Haven't looked at it yet, won't have time until tonight Deadlock around SolrCoreState update lock. -- Key: SOLR-4505 URL: https://issues.apache.org/jira/browse/SOLR-4505 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Erick Erickson Priority: Minor Fix For: 4.2, 5.0 Attachments: newstack.txt, SOLR-4505.patch Erick found a deadlock with his core stress tool - see http://markmail.org/message/aq5hghbqia2uimgl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587203#comment-13587203 ] Commit Tag Bot commented on LUCENE-4798: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revisionrevision=1450220 LUCENE-4798: remove accidentally inserted tabs PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Fix For: 4.2, 5.0 Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types
[ https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587209#comment-13587209 ] Steve Rowe commented on SOLR-4503: -- bq. I have not looked at the patch yet, but in general, I like restlet. It's dual licensed right? One of the licenses compat with Apache? It's quintuply licensed: Apache 2.0 / LGPL 3.0 / LGPL 2.1 / CDDL 1.0 / EPL 1.0 Add REST API methods to get schema information: fields, dynamic fields, and field types --- Key: SOLR-4503 URL: https://issues.apache.org/jira/browse/SOLR-4503 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Affects Versions: 4.1 Reporter: Steve Rowe Assignee: Steve Rowe Attachments: SOLR-4503.patch Add REST methods that provide properties for fields, dynamic fields, and field types, using paths: /solr/(corename)/schema/fields /solr/(corename)/schema/fields/fieldname /solr/(corename)/schema/dynamicfields /solr/(corename)/schema/dynamicfields/pattern /solr/(corename)/schema/fieldtypes /solr/(corename)/schema/fieldtypes/typename -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types
[ https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587213#comment-13587213 ] Mark Miller commented on SOLR-4503: --- Oh nice, Apache 2 - pretty sure they did not offer that back when I was using it. Add REST API methods to get schema information: fields, dynamic fields, and field types --- Key: SOLR-4503 URL: https://issues.apache.org/jira/browse/SOLR-4503 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Affects Versions: 4.1 Reporter: Steve Rowe Assignee: Steve Rowe Attachments: SOLR-4503.patch Add REST methods that provide properties for fields, dynamic fields, and field types, using paths: /solr/(corename)/schema/fields /solr/(corename)/schema/fields/fieldname /solr/(corename)/schema/dynamicfields /solr/(corename)/schema/dynamicfields/pattern /solr/(corename)/schema/fieldtypes /solr/(corename)/schema/fieldtypes/typename -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Lucene-Artifacts-trunk - Build # 2205 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-trunk/2205/ No tests ran. Build Log: [...truncated 1031 lines...] [javac] Compiling 49 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build/highlighter/classes/java [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:79: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(starts[i], starts[j]); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:89: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(pivot, starts[j]); [javac] ^ [javac] 2 errors BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:1746: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/module-build.xml:430: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:472: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:1567: Compile failed; see the compiler error output for details. Total time: 39 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Artifacts-trunk - Build # 2205 - Failure
I caused this. I think my IDE is wrongly configured to use java7 apis... Ill fix On Tue, Feb 26, 2013 at 10:58 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Artifacts-trunk/2205/ No tests ran. Build Log: [...truncated 1031 lines...] [javac] Compiling 49 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build/highlighter/classes/java [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:79: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(starts[i], starts[j]); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:89: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(pivot, starts[j]); [javac] ^ [javac] 2 errors BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:1746: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/module-build.xml:430: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:472: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/common-build.xml:1567: Compile failed; see the compiler error output for details. Total time: 39 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc Email was triggered for: Failure Sending email for trigger: Failure - 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] (SOLR-4490) add support for multivalued docvalues
[ https://issues.apache.org/jira/browse/SOLR-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587218#comment-13587218 ] Commit Tag Bot commented on SOLR-4490: -- [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revisionrevision=1450239 SOLR-4490: multi-valued dv support add support for multivalued docvalues -- Key: SOLR-4490 URL: https://issues.apache.org/jira/browse/SOLR-4490 Project: Solr Issue Type: New Feature Reporter: Robert Muir Attachments: SOLR-4490.patch, SOLR-4490.patch exposing LUCENE-4765 essentially. I think we don't need any new options, it just means doing the right thing when someone has docValues=true and multivalued=true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4798) PostingsHighlighter's formatter sometimes doesnt highlight matched terms
[ https://issues.apache.org/jira/browse/LUCENE-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587223#comment-13587223 ] Commit Tag Bot commented on LUCENE-4798: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revisionrevision=1450246 LUCENE-4798: use java6 compatible method PostingsHighlighter's formatter sometimes doesnt highlight matched terms Key: LUCENE-4798 URL: https://issues.apache.org/jira/browse/LUCENE-4798 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Fix For: 4.2, 5.0 Attachments: LUCENE-4798.patch This can happen if you have a sentence where the query terms match many times in the same sentence: for example if you query on testing highlighter but you have Testing highlighters is sometimes harder than testing other things. The issue is that the formatter receives all 3 matches, but in this order: Testing (first occurrence) testing (second occurrence) highlighters The formatter expects the matches to be in sorted order by offset (not by term, then offset). This is how the javadocs say they should be. But there is currently a bug, a stupid side effect of how the ranking is done. Because of this, in this example highlighters isnt marked up in bold. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Lucene-Solr-Tests-4.x-Java6 - Build # 1374 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1374/ All tests passed Build Log: [...truncated 2346 lines...] [javac] Compiling 49 source files to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/build/highlighter/classes/java [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:79: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(starts[i], starts[j]); [javac] ^ [javac] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/Passage.java:89: cannot find symbol [javac] symbol : method compare(int,int) [javac] location: class java.lang.Integer [javac] return Integer.compare(pivot, starts[j]); [javac] ^ [javac] 2 errors BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:381: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:361: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/common-build.xml:1745: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/module-build.xml:430: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/common-build.xml:472: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/common-build.xml:1567: Compile failed; see the compiler error output for details. Total time: 11 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4490) add support for multivalued docvalues
[ https://issues.apache.org/jira/browse/SOLR-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-4490. --- Resolution: Fixed Fix Version/s: 5.0 4.2 add support for multivalued docvalues -- Key: SOLR-4490 URL: https://issues.apache.org/jira/browse/SOLR-4490 Project: Solr Issue Type: New Feature Reporter: Robert Muir Fix For: 4.2, 5.0 Attachments: SOLR-4490.patch, SOLR-4490.patch exposing LUCENE-4765 essentially. I think we don't need any new options, it just means doing the right thing when someone has docValues=true and multivalued=true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4796) NamedSPILoader.reload needs to be synchronized
[ https://issues.apache.org/jira/browse/LUCENE-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587254#comment-13587254 ] Commit Tag Bot commented on LUCENE-4796: [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1450275 LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs NamedSPILoader.reload needs to be synchronized -- Key: LUCENE-4796 URL: https://issues.apache.org/jira/browse/LUCENE-4796 Project: Lucene - Core Issue Type: Bug Reporter: Hoss Man Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4796.patch, LUCENE-4796.patch Spun off of SOLR-4373: as discsused with uwe on IRC, NamedSPILoader.reload is not thread safe: it reads from this.services at the beginging of hte method, makes additions based on the method input, and then overwrites this.services at the end of the method. if the method is called by two threads concurrently, the entries added by threadB could be lost if threadA enters the method before threadB and exists the method after threadB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587255#comment-13587255
]
Commit Tag Bot commented on SOLR-4373:
--
[trunk commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revisionrevision=1450275
LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and
AnalysisSPILoader when doing concurrent core loads in multicore Solr configs
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4796) NamedSPILoader.reload needs to be synchronized
[ https://issues.apache.org/jira/browse/LUCENE-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4796. --- Resolution: Fixed I committed the fix for the concurrency bug and the incorrect reload starting with empty map instead of old map NamedSPILoader.reload needs to be synchronized -- Key: LUCENE-4796 URL: https://issues.apache.org/jira/browse/LUCENE-4796 Project: Lucene - Core Issue Type: Bug Reporter: Hoss Man Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4796.patch, LUCENE-4796.patch Spun off of SOLR-4373: as discsused with uwe on IRC, NamedSPILoader.reload is not thread safe: it reads from this.services at the beginging of hte method, makes additions based on the method input, and then overwrites this.services at the end of the method. if the method is called by two threads concurrently, the entries added by threadB could be lost if threadA enters the method before threadB and exists the method after threadB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587258#comment-13587258
]
Uwe Schindler commented on SOLR-4373:
-
I think this should be solved by LUCENE-4796, which is committed now. I keep
this issue open until somebody confirms, that the fix is working for Solr.
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587262#comment-13587262 ] Michael McCandless commented on SOLR-3843: -- +1 to add lucene-codecs to Solr: Lucene has a number of useful codec components, growing over time ... I think we should make it as easy as possible for users to access these from Solr. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4796) NamedSPILoader.reload needs to be synchronized
[ https://issues.apache.org/jira/browse/LUCENE-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587263#comment-13587263 ] Commit Tag Bot commented on LUCENE-4796: [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1450276 Merged revision(s) 1450275 from lucene/dev/trunk: LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs NamedSPILoader.reload needs to be synchronized -- Key: LUCENE-4796 URL: https://issues.apache.org/jira/browse/LUCENE-4796 Project: Lucene - Core Issue Type: Bug Reporter: Hoss Man Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4796.patch, LUCENE-4796.patch Spun off of SOLR-4373: as discsused with uwe on IRC, NamedSPILoader.reload is not thread safe: it reads from this.services at the beginging of hte method, makes additions based on the method input, and then overwrites this.services at the end of the method. if the method is called by two threads concurrently, the entries added by threadB could be lost if threadA enters the method before threadB and exists the method after threadB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587264#comment-13587264
]
Commit Tag Bot commented on SOLR-4373:
--
[branch_4x commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revisionrevision=1450276
Merged revision(s) 1450275 from lucene/dev/trunk:
LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and
AnalysisSPILoader when doing concurrent core loads in multicore Solr configs
In multicore, lib directives in solrconfig.xml cause conflict and clobber
directives from earlier cores
---
Key: SOLR-4373
URL: https://issues.apache.org/jira/browse/SOLR-4373
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
Priority: Blocker
Labels: lib, multicore
Fix For: 4.2, 5.0, 4.1.1
Attachments: multicore-bug.zip
Having lib directives in the solrconfig.xml files of multiple cores can cause
problems when using multi-threaded core initialization -- which is the
default starting with Solr 4.1.
The problem manifests itself as init errors in the logs related to not being
able to find classes located in plugin jars, even though earlier log messages
indicated that those jars had been added to the classpath.
One work around is to set {{coreLoadThreads=1}} in your solr.xml file --
forcing single threaded core initialization. For example...
{code}
?xml version=1.0 encoding=utf-8 ?
solr coreLoadThreads=1
cores adminPath=/admin/cores
core name=core1 instanceDir=core1 /
core name=core2 instanceDir=core2 /
/cores
/solr
{code}
(Similar problems may occur if multiple cores are initialized concurrently
using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4642) TokenizerFactory should provide a create method with a given AttributeSource
[ https://issues.apache.org/jira/browse/LUCENE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587269#comment-13587269 ] Renaud Delbru commented on LUCENE-4642: --- Hi, any updates about the patch ? thanks. TokenizerFactory should provide a create method with a given AttributeSource Key: LUCENE-4642 URL: https://issues.apache.org/jira/browse/LUCENE-4642 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.1 Reporter: Renaud Delbru Assignee: Steve Rowe Labels: analysis, attribute, tokenizer Fix For: 4.2, 5.0 Attachments: LUCENE-4642.patch, LUCENE-4642.patch, LUCENE-4642.patch, TrieTokenizerFactory.java.patch All tokenizer implementations have a constructor that takes a given AttributeSource as parameter (LUCENE-1826). However, the TokenizerFactory does not provide an API to create tokenizers with a given AttributeSource. Side note: There are still a lot of tokenizers that do not provide constructors that take AttributeSource and AttributeFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587276#comment-13587276 ] Uwe Schindler commented on SOLR-3843: - -1 To add it to the war. Its so easy to add analyzer JAR files to the solr/lib folder, same applies to codecs. If this DV codec is so important for facetting and sorting and nuking FieldCache, move it to lucene-core.jar. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4802) FacetFields should omitNorms for $facets field
Michael McCandless created LUCENE-4802: -- Summary: FacetFields should omitNorms for $facets field Key: LUCENE-4802 URL: https://issues.apache.org/jira/browse/LUCENE-4802 Project: Lucene - Core Issue Type: Bug Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.2, 5.0 Attachments: LUCENE-4802.patch We are indexing norms today but we only ever filter by these fields ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587281#comment-13587281 ] Robert Muir commented on SOLR-3843: --- So Solr shouldnt bundle any analyzers either? I'm not trying to say that codecs need to be in core, man this is experimental stuff and I definitely dont want to increase our backwards compatibility requirements. I just want to make it easier for users to experiment. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4802) FacetFields should omitNorms for $facets field
[ https://issues.apache.org/jira/browse/LUCENE-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4802: --- Attachment: LUCENE-4802.patch One-line fix + test ... I'll commit shortly. FacetFields should omitNorms for $facets field -- Key: LUCENE-4802 URL: https://issues.apache.org/jira/browse/LUCENE-4802 Project: Lucene - Core Issue Type: Bug Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.2, 5.0 Attachments: LUCENE-4802.patch We are indexing norms today but we only ever filter by these fields ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4642) TokenizerFactory should provide a create method with a given AttributeSource
[ https://issues.apache.org/jira/browse/LUCENE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587283#comment-13587283 ] Steve Rowe commented on LUCENE-4642: Hi Renaud, I skimmed your patch, looks good, I'll take a closer look in the next couple days for completeness and testing. TokenizerFactory should provide a create method with a given AttributeSource Key: LUCENE-4642 URL: https://issues.apache.org/jira/browse/LUCENE-4642 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.1 Reporter: Renaud Delbru Assignee: Steve Rowe Labels: analysis, attribute, tokenizer Fix For: 4.2, 5.0 Attachments: LUCENE-4642.patch, LUCENE-4642.patch, LUCENE-4642.patch, TrieTokenizerFactory.java.patch All tokenizer implementations have a constructor that takes a given AttributeSource as parameter (LUCENE-1826). However, the TokenizerFactory does not provide an API to create tokenizers with a given AttributeSource. Side note: There are still a lot of tokenizers that do not provide constructors that take AttributeSource and AttributeFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4803) DrillDownQuery should rewrite to FilteredQuery?
Michael McCandless created LUCENE-4803: -- Summary: DrillDownQuery should rewrite to FilteredQuery? Key: LUCENE-4803 URL: https://issues.apache.org/jira/browse/LUCENE-4803 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.2, 5.0 Today we rewrite to a query like +baseQuery +ConstantScoreQuery(boost=0.0 TermQuery(drillDownTerm)), but I'm not certain 0.0 boost is safe / doesn't actually change scores. We should also add a test to assert that scores are not changed by drill down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587289#comment-13587289 ] Uwe Schindler commented on SOLR-3843: - If users want to experiment they just need to copypaste a file, where is the problem? In addition: The analysis-extras module is also not needed (except the special ICUField, which may more into a solr-icu module), as all analysis factories are already inside the analyzers jar. In my opinion, the Solr WAR file should only bundle analyzers-common.jar and nothing more. The analysis-extras build.xml file is the worst I have seen: It just copies some JAR files from Lucene to Solr. To make it easier for people, we can add a command that uses get/ivy to download the JAR file from Maven and install it in solr's lib folder. Optional stuff should not be in the WAR file. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (LUCENE-4802) FacetFields should omitNorms for $facets field
[ https://issues.apache.org/jira/browse/LUCENE-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-4802. Resolution: Fixed FacetFields should omitNorms for $facets field -- Key: LUCENE-4802 URL: https://issues.apache.org/jira/browse/LUCENE-4802 Project: Lucene - Core Issue Type: Bug Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.2, 5.0 Attachments: LUCENE-4802.patch We are indexing norms today but we only ever filter by these fields ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4802) FacetFields should omitNorms for $facets field
[ https://issues.apache.org/jira/browse/LUCENE-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587297#comment-13587297 ] Commit Tag Bot commented on LUCENE-4802: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revisionrevision=1450299 LUCENE-4802: omitNorms for facet drilldown fields FacetFields should omitNorms for $facets field -- Key: LUCENE-4802 URL: https://issues.apache.org/jira/browse/LUCENE-4802 Project: Lucene - Core Issue Type: Bug Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.2, 5.0 Attachments: LUCENE-4802.patch We are indexing norms today but we only ever filter by these fields ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587302#comment-13587302 ] Uwe Schindler commented on SOLR-3843: - I could agree to add this for now, but once you committed this: Open a new issue to cleanup solr.war and remove *all* optional stuff (like analyzers-phonetic.jar). Instead add a internet downloader using ivy/maven for setup of solr/lib folder. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4802) FacetFields should omitNorms for $facets field
[ https://issues.apache.org/jira/browse/LUCENE-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587307#comment-13587307 ] Commit Tag Bot commented on LUCENE-4802: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revisionrevision=1450300 LUCENE-4802: omitNorms for facet drilldown fields FacetFields should omitNorms for $facets field -- Key: LUCENE-4802 URL: https://issues.apache.org/jira/browse/LUCENE-4802 Project: Lucene - Core Issue Type: Bug Components: modules/facet Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.2, 5.0 Attachments: LUCENE-4802.patch We are indexing norms today but we only ever filter by these fields ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4504) CurrencyField treats docs w/o value the same as having a value of 0.0
[
https://issues.apache.org/jira/browse/SOLR-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587308#comment-13587308
]
Commit Tag Bot commented on SOLR-4504:
--
[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1450304
SOLR-4504: Fixed CurrencyField range queries to correctly exclude documents w/o
values
CurrencyField treats docs w/o value the same as having a value of 0.0
-
Key: SOLR-4504
URL: https://issues.apache.org/jira/browse/SOLR-4504
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 4.2
Attachments: SOLR-4504.patch
As noted by Gerald Blank on the mailing list, CurrencyField queries treat
documents w/o any value the same as documents wit ha value of 0.0f.
observe that using the example solr schema, with any number of docs indexed,
this query matches all docs even though no docs have any values at all for
hte specified field...
{noformat}
http://localhost:8983/solr/select?q=hoss_c:[*%20TO%20*]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587309#comment-13587309 ] Mark Miller commented on SOLR-3843: --- bq. If users want to experiment they just need to copypaste a file, where is the problem? That it's much easier to not have to copy past a file? At the sizes of the files involved, your just being a masochist :) Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (LUCENE-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
[ https://issues.apache.org/jira/browse/LUCENE-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned LUCENE-4801: Assignee: Hoss Man bq. The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? Looks like the class level javadocs got overlooked when the whole similarity API contract got revamped -- i'll remove all those references to global setters. bq. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? I thought so, but it doesn't look like it -- apparently SOLR-1365 never got finalized after SOLR-2338 was committed Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity - Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen Assignee: Hoss Man Priority: Minor Labels: documentation The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4803) DrillDownQuery should rewrite to FilteredQuery?
[ https://issues.apache.org/jira/browse/LUCENE-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587329#comment-13587329 ] Commit Tag Bot commented on LUCENE-4803: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revisionrevision=1450320 LUCENE-4803: add test coverage DrillDownQuery should rewrite to FilteredQuery? --- Key: LUCENE-4803 URL: https://issues.apache.org/jira/browse/LUCENE-4803 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.2, 5.0 Today we rewrite to a query like +baseQuery +ConstantScoreQuery(boost=0.0 TermQuery(drillDownTerm)), but I'm not certain 0.0 boost is safe / doesn't actually change scores. We should also add a test to assert that scores are not changed by drill down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4803) DrillDownQuery should rewrite to FilteredQuery?
[ https://issues.apache.org/jira/browse/LUCENE-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587330#comment-13587330 ] Michael McCandless commented on LUCENE-4803: I committed test coverage, asserting that DDQ never alters the scores of the original query, and it seems to be passing ... I'll leave this open (but not work on it for now...) to explore whether we should use FilteredQuery instead. Our Filter would not be random access (we'd just do QueryWrapperFilter(BQ(+dd1 +dd2 +dd3 ...)) ... not sure if we'd see perf changes with FilteredQuery. DrillDownQuery should rewrite to FilteredQuery? --- Key: LUCENE-4803 URL: https://issues.apache.org/jira/browse/LUCENE-4803 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.2, 5.0 Today we rewrite to a query like +baseQuery +ConstantScoreQuery(boost=0.0 TermQuery(drillDownTerm)), but I'm not certain 0.0 boost is safe / doesn't actually change scores. We should also add a test to assert that scores are not changed by drill down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Assigned] (SOLR-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-4310: -- Assignee: Hoss Man Amit: thanks for this patch. The conceptual change makes sense to me, and the patch itself seems straight forward. if you can update the patch to include some test additions (both to the single node and distributed grouping tests) i'll get it committed. If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4504) CurrencyField treats docs w/o value the same as having a value of 0.0
[
https://issues.apache.org/jira/browse/SOLR-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-4504.
Resolution: Fixed
Fix Version/s: 5.0
Committed revision 1450304.
Committed revision 1450331.
CurrencyField treats docs w/o value the same as having a value of 0.0
-
Key: SOLR-4504
URL: https://issues.apache.org/jira/browse/SOLR-4504
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 4.2, 5.0
Attachments: SOLR-4504.patch
As noted by Gerald Blank on the mailing list, CurrencyField queries treat
documents w/o any value the same as documents wit ha value of 0.0f.
observe that using the example solr schema, with any number of docs indexed,
this query matches all docs even though no docs have any values at all for
hte specified field...
{noformat}
http://localhost:8983/solr/select?q=hoss_c:[*%20TO%20*]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4310) If groups.ngroups is specified, the docList's numFound should be the number of groups
[ https://issues.apache.org/jira/browse/SOLR-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587343#comment-13587343 ] Amit Nithian commented on SOLR-4310: Sure let me work on that and resubmit! Thanks If groups.ngroups is specified, the docList's numFound should be the number of groups - Key: SOLR-4310 URL: https://issues.apache.org/jira/browse/SOLR-4310 Project: Solr Issue Type: Improvement Components: search Affects Versions: 4.1 Reporter: Amit Nithian Assignee: Hoss Man Priority: Minor Fix For: 4.2 Attachments: SOLR-4310.patch If you group by a field, the response may look like this: lst name=grouped lst name=series int name=matches138/int int name=ngroups1/int result name=doclist numFound=138 start=0 doc int name=id267038365/int str name=name Larry's Grand Ole Garage Country Dance - Pure Country /str /doc /result /lst /lst and if you specify group.main then the doclist becomes the result and you lose all context of the number of groups. If you want to keep your response format backwards compatible with clients (i.e. clients who don't know about the grouped format), setting group.main=true solves this BUT the numFound is the number of raw matches instead of the number of groups. This may have downstream consequences. I'd like to propose that if the user specifies ngroups=true then when creating the returning DocSlice, set the numFound to be the number of groups instead of the number of raw matches to keep the response consistent with what the user would expect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4803) DrillDownQuery should rewrite to FilteredQuery?
[ https://issues.apache.org/jira/browse/LUCENE-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587345#comment-13587345 ] Commit Tag Bot commented on LUCENE-4803: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revisionrevision=1450321 LUCENE-4803: add test coverage DrillDownQuery should rewrite to FilteredQuery? --- Key: LUCENE-4803 URL: https://issues.apache.org/jira/browse/LUCENE-4803 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Fix For: 4.2, 5.0 Today we rewrite to a query like +baseQuery +ConstantScoreQuery(boost=0.0 TermQuery(drillDownTerm)), but I'm not certain 0.0 boost is safe / doesn't actually change scores. We should also add a test to assert that scores are not changed by drill down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4504) CurrencyField treats docs w/o value the same as having a value of 0.0
[
https://issues.apache.org/jira/browse/SOLR-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587356#comment-13587356
]
Commit Tag Bot commented on SOLR-4504:
--
[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1450331
SOLR-4504: Fixed CurrencyField range queries to correctly exclude documents w/o
values (merge r1450304)
CurrencyField treats docs w/o value the same as having a value of 0.0
-
Key: SOLR-4504
URL: https://issues.apache.org/jira/browse/SOLR-4504
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 4.2, 5.0
Attachments: SOLR-4504.patch
As noted by Gerald Blank on the mailing list, CurrencyField queries treat
documents w/o any value the same as documents wit ha value of 0.0f.
observe that using the example solr schema, with any number of docs indexed,
this query matches all docs even though no docs have any values at all for
hte specified field...
{noformat}
http://localhost:8983/solr/select?q=hoss_c:[*%20TO%20*]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Code reformatted to Lucene style. Seems to look good in intellij and vi. Configurable Collectors --- Key: SOLR-4465 URL: https://issues.apache.org/jira/browse/SOLR-4465 Project: Solr Issue Type: New Feature Components: search Affects Versions: 4.1 Reporter: Joel Bernstein Fix For: 4.2, 5.0 Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4797) Fix remaining Lucene/Solr Javadocs issue
[ https://issues.apache.org/jira/browse/LUCENE-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587364#comment-13587364 ] Hoss Man commented on LUCENE-4797: -- Uwe: would it be easy to setup a jenkins instance running the full build using JDK8, just w/o the build failure email notifications? then even people w/o JDK8 installed (or the inclination to constantly keep up with the beta builds) could still see look at the list of doc failures/warnings under JDK8 and help out with fixes. Fix remaining Lucene/Solr Javadocs issue Key: LUCENE-4797 URL: https://issues.apache.org/jira/browse/LUCENE-4797 Project: Lucene - Core Issue Type: Bug Components: general/javadocs Affects Versions: 4.1 Reporter: Uwe Schindler Java 8 has a new feature (enabled by default): http://openjdk.java.net/jeps/172 It fails the build on: - incorrect links (@see, @link,...) - incorrect HTML entities - invalid HTML in general Thanks to our linter written in HTMLTidy and Python, most of the bugs are already solved in our source code, but the Oracle Linter finds some more problems, our linter does not: - missing escapes - invalid entities Unfortunately the versions of JDK8 released up to today have a bug, making optional closing tags (which are valid HTML4), like /p, mandatory. This will be fixed in b78. Currently there is another bug in the Oracle javadocs tool (it fails to copy doc-files folders), but this is under investigation at the moment. We should clean up our javadocs, so the pass the new JDK8 javadocs tool with build 78+. Maybe we can put our own linter out of service, once we rely on Java 8 :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
[ https://issues.apache.org/jira/browse/LUCENE-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587368#comment-13587368 ] Commit Tag Bot commented on LUCENE-4801: [trunk commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revisionrevision=1450342 LUCENE-4801: lingering doc remnants from pre-4.0 similarity API Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity - Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen Assignee: Hoss Man Priority: Minor Labels: documentation The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (LUCENE-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
[ https://issues.apache.org/jira/browse/LUCENE-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved LUCENE-4801. -- Resolution: Fixed Fix Version/s: 5.0 4.2 Committed revision 1450342. Committed revision 1450344. Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity - Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen Assignee: Hoss Man Priority: Minor Labels: documentation Fix For: 4.2, 5.0 The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4797) Fix remaining Lucene/Solr Javadocs issue
[ https://issues.apache.org/jira/browse/LUCENE-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587372#comment-13587372 ] Robert Muir commented on LUCENE-4797: - I think realistically the p tag bug, combined with the lack of copying doc-files would make the output somewhat useless today. If they can fix these two bugs, i'm sure we can easily fix any remaining real issues quickly. Then we are able to see if we still encounter the hotspot bug where it miscompiles something and causes all tests to fail Fix remaining Lucene/Solr Javadocs issue Key: LUCENE-4797 URL: https://issues.apache.org/jira/browse/LUCENE-4797 Project: Lucene - Core Issue Type: Bug Components: general/javadocs Affects Versions: 4.1 Reporter: Uwe Schindler Java 8 has a new feature (enabled by default): http://openjdk.java.net/jeps/172 It fails the build on: - incorrect links (@see, @link,...) - incorrect HTML entities - invalid HTML in general Thanks to our linter written in HTMLTidy and Python, most of the bugs are already solved in our source code, but the Oracle Linter finds some more problems, our linter does not: - missing escapes - invalid entities Unfortunately the versions of JDK8 released up to today have a bug, making optional closing tags (which are valid HTML4), like /p, mandatory. This will be fixed in b78. Currently there is another bug in the Oracle javadocs tool (it fails to copy doc-files folders), but this is under investigation at the moment. We should clean up our javadocs, so the pass the new JDK8 javadocs tool with build 78+. Maybe we can put our own linter out of service, once we rely on Java 8 :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4801) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity
[ https://issues.apache.org/jira/browse/LUCENE-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587379#comment-13587379 ] Commit Tag Bot commented on LUCENE-4801: [branch_4x commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revisionrevision=1450344 LUCENE-4801: lingering doc remnants from pre-4.0 similarity API (merge r1450342) Documentation is incorrect for org.apache.lucene.misc.SweetSpotSimilarity - Key: LUCENE-4801 URL: https://issues.apache.org/jira/browse/LUCENE-4801 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 4.0-ALPHA Reporter: Andrew Schoen Assignee: Hoss Man Priority: Minor Labels: documentation Fix For: 4.2, 5.0 The documentation for SweetSpotSimilarity says that you can configure a global min/max and also a min/max per field, however at looking at the source and just trying to accomplish this it looks as though it's not possible. Is that correct? I looked into using SchemaSimilarityFactory as a global Similarity and then using SweetSpotSimilarity on a fieldType, but was not able to configure the min and max values. Is there a way to accomplish that without writing my own SweetSpotSimilarityFactory? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587409#comment-13587409 ] Markus Jelsma commented on SOLR-4465: - This is very cool Joel! I'm sure to rewrite our SolrIndexSearcher and custom collections to use this factory. Will you also allow collectors to return a numeric value which will be written to the output in response builder? Configurable Collectors --- Key: SOLR-4465 URL: https://issues.apache.org/jira/browse/SOLR-4465 Project: Solr Issue Type: New Feature Components: search Affects Versions: 4.1 Reporter: Joel Bernstein Fix For: 4.2, 5.0 Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4480) EDisMax parser blows up with query containing single plus or minus
[
https://issues.apache.org/jira/browse/SOLR-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-4480:
---
Attachment: SOLR-4480.patch
I started off trying to modify the parser grammar, but it quickly went down a
rat hole...
Instead, here's a patch that lets the JavaCC parser fail, and makes the
escaping better for edismax.
EDisMax parser blows up with query containing single plus or minus
--
Key: SOLR-4480
URL: https://issues.apache.org/jira/browse/SOLR-4480
Project: Solr
Issue Type: Bug
Components: query parsers
Reporter: Fiona Tay
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-4480.patch, SOLR-4480.patch, SOLR-4480.patch
We are running solr with sunspot and when we set up a query containing a
single plus, Solr blows up with the following error:
SOLR Request (5.0ms) [ path=#RSolr::Client:0x4c7464ac parameters={data:
fq=type%3A%28Attachment+OR+User+OR+GpdbDataSource+OR+HadoopInstance+OR+GnipInstance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=type_name_s%3A%28Attachment+OR+User+OR+Instance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29q=%2Bfl=%2A+scoreqf=name_texts+first_name_texts+last_name_texts+file_name_textsdefType=edismaxhl=onhl.simple.pre=%40%40%40hl%40%40%40hl.simple.post=%40%40%40endhl%40%40%40start=0rows=3,
method: post, params: {:wt=:ruby}, query: wt=ruby, headers:
{Content-Type=application/x-www-form-urlencoded; charset=UTF-8}, path:
select, uri: http://localhost:8982/solr/select?wt=ruby, open_timeout: ,
read_timeout: } ]
RSolr::Error::Http (RSolr::Error::Http - 400 Bad Request
Error: org.apache.lucene.queryParser.ParseException: Cannot parse '':
Encountered EOF at line 1, column 0.
Was expecting one of:
NOT ...
+ ...
- ...
( ...
* ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587421#comment-13587421 ] Uwe Schindler commented on SOLR-3843: - OK, then we can also remove the modules in Lucene completely! Let's just create a 8 MB lucene.jar file. We have modules to make this possible and let users start with a small installation without useless stuff they will never need... This is just my opinion, but to me it looks we can get rid of all modules, have one big build.xml, one big classpath and finally have only one big JAR file for Lucene and Solr - but that's real masochism, especially for projects like ES! Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4797) Fix remaining Lucene/Solr Javadocs issue
[ https://issues.apache.org/jira/browse/LUCENE-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587431#comment-13587431 ] Uwe Schindler commented on LUCENE-4797: --- We already have a JDK8 build, so there is no action to take. I am just waiting for the confirmation from Oracle that the bug with doc-files is fixed. The number of fixes needed is small, I will take the issue once a functional JDK8 is out. Fix remaining Lucene/Solr Javadocs issue Key: LUCENE-4797 URL: https://issues.apache.org/jira/browse/LUCENE-4797 Project: Lucene - Core Issue Type: Bug Components: general/javadocs Affects Versions: 4.1 Reporter: Uwe Schindler Java 8 has a new feature (enabled by default): http://openjdk.java.net/jeps/172 It fails the build on: - incorrect links (@see, @link,...) - incorrect HTML entities - invalid HTML in general Thanks to our linter written in HTMLTidy and Python, most of the bugs are already solved in our source code, but the Oracle Linter finds some more problems, our linter does not: - missing escapes - invalid entities Unfortunately the versions of JDK8 released up to today have a bug, making optional closing tags (which are valid HTML4), like /p, mandatory. This will be fixed in b78. Currently there is another bug in the Oracle javadocs tool (it fails to copy doc-files folders), but this is under investigation at the moment. We should clean up our javadocs, so the pass the new JDK8 javadocs tool with build 78+. Maybe we can put our own linter out of service, once we rely on Java 8 :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[
https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587432#comment-13587432
]
Robert Muir commented on SOLR-3843:
---
{quote}
OK, then we can also remove the modules in Lucene completely! Let's just create
a 8 MB lucene.jar file.
{quote}
This would be a 20MB jar. If you included their dependencies so it actually
functioned correctly, 43MB.
Add lucene-codecs to Solr libs?
---
Key: SOLR-3843
URL: https://issues.apache.org/jira/browse/SOLR-3843
Project: Solr
Issue Type: Wish
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch
Solr gives the ability to its users to select the postings format to use on a
per-field basis but only Lucene40PostingsFormat is available by default
(unless users add lucene-codecs to the Solr lib directory). Maybe we should
add lucene-codecs to Solr libs (I mean in the WAR file) so that people can
try our non-default postings formats with minimum effort?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-4797) Fix remaining Lucene/Solr Javadocs issue
[ https://issues.apache.org/jira/browse/LUCENE-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587431#comment-13587431 ] Uwe Schindler edited comment on LUCENE-4797 at 2/26/13 7:29 PM: We already have a JDK8 build, so there is no action to take. I am just waiting for the confirmation from Oracle that the bug with doc-files is fixed. The number of fixes needed on our side is small, I will take the issue once a functional JDK8 is out. The issue with optional end elements (/p) is already fixed in their b78 branch. was (Author: thetaphi): We already have a JDK8 build, so there is no action to take. I am just waiting for the confirmation from Oracle that the bug with doc-files is fixed. The number of fixes needed is small, I will take the issue once a functional JDK8 is out. Fix remaining Lucene/Solr Javadocs issue Key: LUCENE-4797 URL: https://issues.apache.org/jira/browse/LUCENE-4797 Project: Lucene - Core Issue Type: Bug Components: general/javadocs Affects Versions: 4.1 Reporter: Uwe Schindler Java 8 has a new feature (enabled by default): http://openjdk.java.net/jeps/172 It fails the build on: - incorrect links (@see, @link,...) - incorrect HTML entities - invalid HTML in general Thanks to our linter written in HTMLTidy and Python, most of the bugs are already solved in our source code, but the Oracle Linter finds some more problems, our linter does not: - missing escapes - invalid entities Unfortunately the versions of JDK8 released up to today have a bug, making optional closing tags (which are valid HTML4), like /p, mandatory. This will be fixed in b78. Currently there is another bug in the Oracle javadocs tool (it fails to copy doc-files folders), but this is under investigation at the moment. We should clean up our javadocs, so the pass the new JDK8 javadocs tool with build 78+. Maybe we can put our own linter out of service, once we rely on Java 8 :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4480) EDisMax parser blows up with query containing single plus or minus
[
https://issues.apache.org/jira/browse/SOLR-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587444#comment-13587444
]
Commit Tag Bot commented on SOLR-4480:
--
[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1450369
SOLR-4480: edismax - fix trailing +-
EDisMax parser blows up with query containing single plus or minus
--
Key: SOLR-4480
URL: https://issues.apache.org/jira/browse/SOLR-4480
Project: Solr
Issue Type: Bug
Components: query parsers
Reporter: Fiona Tay
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-4480.patch, SOLR-4480.patch, SOLR-4480.patch
We are running solr with sunspot and when we set up a query containing a
single plus, Solr blows up with the following error:
SOLR Request (5.0ms) [ path=#RSolr::Client:0x4c7464ac parameters={data:
fq=type%3A%28Attachment+OR+User+OR+GpdbDataSource+OR+HadoopInstance+OR+GnipInstance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=type_name_s%3A%28Attachment+OR+User+OR+Instance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29q=%2Bfl=%2A+scoreqf=name_texts+first_name_texts+last_name_texts+file_name_textsdefType=edismaxhl=onhl.simple.pre=%40%40%40hl%40%40%40hl.simple.post=%40%40%40endhl%40%40%40start=0rows=3,
method: post, params: {:wt=:ruby}, query: wt=ruby, headers:
{Content-Type=application/x-www-form-urlencoded; charset=UTF-8}, path:
select, uri: http://localhost:8982/solr/select?wt=ruby, open_timeout: ,
read_timeout: } ]
RSolr::Error::Http (RSolr::Error::Http - 400 Bad Request
Error: org.apache.lucene.queryParser.ParseException: Cannot parse '':
Encountered EOF at line 1, column 0.
Was expecting one of:
NOT ...
+ ...
- ...
( ...
* ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4480) EDisMax parser blows up with query containing single plus or minus
[
https://issues.apache.org/jira/browse/SOLR-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-4480.
Resolution: Fixed
EDisMax parser blows up with query containing single plus or minus
--
Key: SOLR-4480
URL: https://issues.apache.org/jira/browse/SOLR-4480
Project: Solr
Issue Type: Bug
Components: query parsers
Reporter: Fiona Tay
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-4480.patch, SOLR-4480.patch, SOLR-4480.patch
We are running solr with sunspot and when we set up a query containing a
single plus, Solr blows up with the following error:
SOLR Request (5.0ms) [ path=#RSolr::Client:0x4c7464ac parameters={data:
fq=type%3A%28Attachment+OR+User+OR+GpdbDataSource+OR+HadoopInstance+OR+GnipInstance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=type_name_s%3A%28Attachment+OR+User+OR+Instance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29q=%2Bfl=%2A+scoreqf=name_texts+first_name_texts+last_name_texts+file_name_textsdefType=edismaxhl=onhl.simple.pre=%40%40%40hl%40%40%40hl.simple.post=%40%40%40endhl%40%40%40start=0rows=3,
method: post, params: {:wt=:ruby}, query: wt=ruby, headers:
{Content-Type=application/x-www-form-urlencoded; charset=UTF-8}, path:
select, uri: http://localhost:8982/solr/select?wt=ruby, open_timeout: ,
read_timeout: } ]
RSolr::Error::Http (RSolr::Error::Http - 400 Bad Request
Error: org.apache.lucene.queryParser.ParseException: Cannot parse '':
Encountered EOF at line 1, column 0.
Was expecting one of:
NOT ...
+ ...
- ...
( ...
* ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4480) EDisMax parser blows up with query containing single plus or minus
[
https://issues.apache.org/jira/browse/SOLR-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587459#comment-13587459
]
Commit Tag Bot commented on SOLR-4480:
--
[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1450371
SOLR-4480: edismax - fix trailing +-
EDisMax parser blows up with query containing single plus or minus
--
Key: SOLR-4480
URL: https://issues.apache.org/jira/browse/SOLR-4480
Project: Solr
Issue Type: Bug
Components: query parsers
Reporter: Fiona Tay
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-4480.patch, SOLR-4480.patch, SOLR-4480.patch
We are running solr with sunspot and when we set up a query containing a
single plus, Solr blows up with the following error:
SOLR Request (5.0ms) [ path=#RSolr::Client:0x4c7464ac parameters={data:
fq=type%3A%28Attachment+OR+User+OR+GpdbDataSource+OR+HadoopInstance+OR+GnipInstance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=type_name_s%3A%28Attachment+OR+User+OR+Instance+OR+Workspace+OR+Workfile+OR+Tag+OR+Dataset+OR+HdfsEntry%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29fq=-%28security_type_name_sm%3A%28Dataset%29+AND+-instance_account_ids_im%3A%282+OR+1%29%29fq=-%28security_type_name_sm%3AChorusView+AND+-member_ids_im%3A1+AND+-public_b%3Atrue%29q=%2Bfl=%2A+scoreqf=name_texts+first_name_texts+last_name_texts+file_name_textsdefType=edismaxhl=onhl.simple.pre=%40%40%40hl%40%40%40hl.simple.post=%40%40%40endhl%40%40%40start=0rows=3,
method: post, params: {:wt=:ruby}, query: wt=ruby, headers:
{Content-Type=application/x-www-form-urlencoded; charset=UTF-8}, path:
select, uri: http://localhost:8982/solr/select?wt=ruby, open_timeout: ,
read_timeout: } ]
RSolr::Error::Http (RSolr::Error::Http - 400 Bad Request
Error: org.apache.lucene.queryParser.ParseException: Cannot parse '':
Encountered EOF at line 1, column 0.
Was expecting one of:
NOT ...
+ ...
- ...
( ...
* ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587460#comment-13587460 ] Mark Miller commented on SOLR-3843: --- Modules in Lucene have little to do with Solr. We shouldn't make users work to save 300k in the webapp. This is super silly stuff... Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587469#comment-13587469 ] Yonik Seeley commented on SOLR-4465: Could you share some of the use cases for this feature? We already have the ability to insert collectors via a custom query that implements the PostFilter interface. Configurable Collectors --- Key: SOLR-4465 URL: https://issues.apache.org/jira/browse/SOLR-4465 Project: Solr Issue Type: New Feature Components: search Affects Versions: 4.1 Reporter: Joel Bernstein Fix For: 4.2, 5.0 Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3843) Add lucene-codecs to Solr libs?
[
https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587477#comment-13587477
]
Uwe Schindler commented on SOLR-3843:
-
Have you looked at ElasticSearch? Its very tiny (20 MB alltogether), no useless
analyzers for every language on earth. If you need kumoroji, enter:
{noformat}
bin/plugin -install elasticsearch/elasticsearch-analysis-kuromoji
{noformat}
This downloads the plugin and installs it into the ES lib folder. This is how
it should work, instead of one horrible huge war file.
But it bundles lucene-codecs.jar, but that has another reason (I think it uses
bloom, as far as I remember).
Add lucene-codecs to Solr libs?
---
Key: SOLR-3843
URL: https://issues.apache.org/jira/browse/SOLR-3843
Project: Solr
Issue Type: Wish
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Critical
Fix For: 4.2, 5.0
Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch
Solr gives the ability to its users to select the postings format to use on a
per-field basis but only Lucene40PostingsFormat is available by default
(unless users add lucene-codecs to the Solr lib directory). Maybe we should
add lucene-codecs to Solr libs (I mean in the WAR file) so that people can
try our non-default postings formats with minimum effort?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587481#comment-13587481
]
Yonik Seeley commented on LUCENE-4800:
--
bq. the current patch will return 'true' for NaN
heh - good catch. Changing to !(floatValue(doc) == 0) should work.
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587481#comment-13587481
]
Yonik Seeley edited comment on LUCENE-4800 at 2/26/13 8:16 PM:
---
bq. the current patch will return 'true' for NaN
heh - good catch. Changing to !(floatValue(doc) == 0) should work.
edit: actually I'm not sure we want NaN to return false... I just tried C, and
NaN evaluates to true. Only 0 evaluates to false.
was (Author: ysee...@gmail.com):
bq. the current patch will return 'true' for NaN
heh - good catch. Changing to !(floatValue(doc) == 0) should work.
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4800) FloatDocValues does not return true for 0 1 values
[
https://issues.apache.org/jira/browse/LUCENE-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587487#comment-13587487
]
Markus Jelsma commented on LUCENE-4800:
---
I'll look into it. I assume NaN would also be a problem for other numeric
DocValues?
FloatDocValues does not return true for 0 1 values
-
Key: LUCENE-4800
URL: https://issues.apache.org/jira/browse/LUCENE-4800
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1427825:1444730M - markus - 2013-02-11
11:39:54
Reporter: Markus Jelsma
Fix For: 5.0
Attachments: LUCENE-4800-trunk.patch
The following function query should always yield 1 if the document's field
matchers the query:
{code}if(query({!lucene df=FIELD v=$q},0),1,0){code}
This is, however, not true if due to low IDF the score end up below 1 but,
obviously, above 0. The if() statement does not recognize a number between
zero and one as positive and therefore TRUE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587494#comment-13587494 ] Mark Miller commented on SOLR-3843: --- Your talking about something completely different - I'm talking about adding 300k to a webapp - sounds like you want to file a different JIRA issue that has little to do with that. In the modern day, I have no problem with the Solr dist - I'd much rather get everything simply as we do than have to stitch crap together. I have disk space and bandwidth as does the majority of the modern world now. If you are offering to write a package manager for solr for unix/windows/mac, please go ahead :) But until then, it makes no sense to not include the codecs the same way we do with analyzers and spellchecker and highlighter, and whatever else we need. If I had to run 10 commands to get solr, get spellchecking, get analyzers, get highlighing, get QueryParsers, get MoreLikeThis, etc, I would shoot myself. Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Affects Versions: 4.0 Reporter: Adrien Grand Priority: Critical Fix For: 4.2, 5.0 Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587519#comment-13587519 ] Joel Bernstein commented on SOLR-4465: -- Sure. One use case would be to control distribution of document types within a result set. For example if you wanted to ensure that each page had 10% of content type A and 50% of type B and 40% of type C. You could insert a custom collector that would manage this. The mergeIds() method would becomes part of the collectorFactory so that the algorithm used at the shard level could be maintained over distributed search. Configurable Collectors --- Key: SOLR-4465 URL: https://issues.apache.org/jira/browse/SOLR-4465 Project: Solr Issue Type: New Feature Components: search Affects Versions: 4.1 Reporter: Joel Bernstein Fix For: 4.2, 5.0 Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4804) PostingsHighlighter sometimes applies term to the wrong passage
Robert Muir created LUCENE-4804: --- Summary: PostingsHighlighter sometimes applies term to the wrong passage Key: LUCENE-4804 URL: https://issues.apache.org/jira/browse/LUCENE-4804 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4804_test.patch There is an off-by-one if the term starts exactly on a sentence boundary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4804) PostingsHighlighter sometimes applies term to the wrong passage
[ https://issues.apache.org/jira/browse/LUCENE-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4804: Attachment: LUCENE-4804_test.patch A simple test and an assert for it added to the random test. But I havent created a fix yet. PostingsHighlighter sometimes applies term to the wrong passage --- Key: LUCENE-4804 URL: https://issues.apache.org/jira/browse/LUCENE-4804 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4804_test.patch There is an off-by-one if the term starts exactly on a sentence boundary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_41) - Build # 4466 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4466/ Java: 64bit/jdk1.6.0_41 -XX:+UseSerialGC 3 tests failed. REGRESSION: org.apache.lucene.queryparser.classic.TestQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace: java.lang.AssertionError: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ at __randomizedtesting.SeedInfo.seed([D1CE88CC65FC075B:6EEBBD12A763A1F1]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.queryparser.util.QueryParserTestBase.assertQueryEquals(QueryParserTestBase.java:161) at org.apache.lucene.queryparser.util.QueryParserTestBase.testCJK(QueryParserTestBase.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:662) REGRESSION: org.apache.lucene.queryparser.ext.TestExtendableQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace: java.lang.AssertionError: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ at __randomizedtesting.SeedInfo.seed([D1CE88CC65FC075B:6EEBBD12A763A1F1]:0) at org.junit.Assert.fail(Assert.java:93) at
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_41) - Build # 4466 - Failure!
Fairly certain i broke this with my mocktokenizer commit... Lemme investigate On Tue, Feb 26, 2013 at 4:28 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4466/ Java: 64bit/jdk1.6.0_41 -XX:+UseSerialGC 3 tests failed. REGRESSION: org.apache.lucene.queryparser.classic.TestQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace: java.lang.AssertionError: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ at __randomizedtesting.SeedInfo.seed([D1CE88CC65FC075B:6EEBBD12A763A1F1]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.queryparser.util.QueryParserTestBase.assertQueryEquals(QueryParserTestBase.java:161) at org.apache.lucene.queryparser.util.QueryParserTestBase.testCJK(QueryParserTestBase.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:662) REGRESSION: org.apache.lucene.queryparser.ext.TestExtendableQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace:
[jira] [Updated] (LUCENE-4804) PostingsHighlighter sometimes applies term to the wrong passage
[ https://issues.apache.org/jira/browse/LUCENE-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4804: Attachment: LUCENE-4804.patch stupid bug, a that should = PostingsHighlighter sometimes applies term to the wrong passage --- Key: LUCENE-4804 URL: https://issues.apache.org/jira/browse/LUCENE-4804 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4804.patch, LUCENE-4804_test.patch There is an off-by-one if the term starts exactly on a sentence boundary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 259 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/259/ Java: 64bit/jdk1.7.0 -XX:+UseG1GC 3 tests failed. REGRESSION: org.apache.lucene.queryparser.classic.TestQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace: java.lang.AssertionError: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ at __randomizedtesting.SeedInfo.seed([FE2E74ED889EE38B:410B41334A014521]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.queryparser.util.QueryParserTestBase.assertQueryEquals(QueryParserTestBase.java:161) at org.apache.lucene.queryparser.util.QueryParserTestBase.testCJK(QueryParserTestBase.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) REGRESSION: org.apache.lucene.queryparser.ext.TestExtendableQueryParser.testCJK Error Message: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ Stack Trace: java.lang.AssertionError: Query /用語 用語 用語/ yielded //, expecting /用語 用語 用語/ at __randomizedtesting.SeedInfo.seed([FE2E74ED889EE38B:410B41334A014521]:0) at org.junit.Assert.fail(Assert.java:93) at
[jira] [Commented] (LUCENE-4804) PostingsHighlighter sometimes applies term to the wrong passage
[ https://issues.apache.org/jira/browse/LUCENE-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587594#comment-13587594 ] Michael McCandless commented on LUCENE-4804: +1, also sneaky! PostingsHighlighter sometimes applies term to the wrong passage --- Key: LUCENE-4804 URL: https://issues.apache.org/jira/browse/LUCENE-4804 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-4804.patch, LUCENE-4804_test.patch There is an off-by-one if the term starts exactly on a sentence boundary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
