Re: Version field as DV
In general DocValues were built to support large scale random access use cases such as faceting and sorting. They have similar performance characteristics as the FieldCache. But unlike the FieldCache you can trade off memory and performance by selecting different DocValues formats. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 10:41 AM, Ishan Chattopadhyaya ichattopadhy...@gmail.com wrote: Hi all, I am looking to try out _version_ as a docvalue (SOLR-6337) as a precursor to SOLR-5944. Towards that, I want the _version_ field to be stored=indexed=false, docValues=true. Does someone know about the performance implications of retrieving the _version_ as a docvalue, e.g. accessing docvalue vs. a stored field? Is there any known inefficiency when using a docvalue (as opposed to a stored field) due to random disk seeks, for example? Regards, Ishan
[jira] [Commented] (SOLR-7605) TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with redundent inner value
[
https://issues.apache.org/jira/browse/SOLR-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596150#comment-14596150
]
Hoss Man commented on SOLR-7605:
steve: definitely a diff problem. can you please open a new issue with the
seed, branch svn r# ?
(at quick glance, this may just be a case of not a loose enough delta in double
comparisons)
TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with
redundent inner value
---
Key: SOLR-7605
URL: https://issues.apache.org/jira/browse/SOLR-7605
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.3, Trunk
There have been two recent jenkins failures of TestCloudPivotFacet on both 5x
and trunk with the same underlying cause...
{noformat}
pProblem accessing /collection1/select. Reason:
prejava.lang.AssertionError: Must not add duplicate PivotFacetValue
with redundent inner value/pre/p
{noformat}
..digging through mail logs, it looks like there have been a handful of these
errors on different branches and os, with and w/o nightly, since April 1st of
this year.
The two recent seeds i tried (on trunk and 5x) reproduce - details to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6548) Optimize BlockTree's Terms.intersect a bit for very finite automata
[ https://issues.apache.org/jira/browse/LUCENE-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596208#comment-14596208 ] Michael McCandless commented on LUCENE-6548: I'll commit the last patch soon; I think there are other things we can do here, but we can explore them later and this is already a good speedup, at lease in the very finite (arcs that typically have only one label, not a range) automata intersect case. Optimize BlockTree's Terms.intersect a bit for very finite automata - Key: LUCENE-6548 URL: https://issues.apache.org/jira/browse/LUCENE-6548 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6548.patch, LUCENE-6548.patch, LUCENE-6548.patch I've been digging into why BlockTree's Terms.intersect impl is slower for a very finite union-of-terms test over random IDs (LUCENE-3893) and I found a few performance improvements that at least for that one use case gets a ~11% speedup. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs
[ https://issues.apache.org/jira/browse/LUCENE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596184#comment-14596184 ] Adrien Grand commented on LUCENE-6588: -- It's good to me this way, I had just forgotten that some child documents could seem deleted because of FilteredQuery. The patch looks good to me so I'll run more tests tomorrow and commit if there are no objections. ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs - Key: LUCENE-6588 URL: https://issues.apache.org/jira/browse/LUCENE-6588 Project: Lucene - Core Issue Type: Bug Components: modules/join Affects Versions: 5.2.1 Reporter: Christoph Kaser Attachments: 0001-Test-score-calculation.patch, 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 0003-implements-ToChildBlockJoinQuery.explain.patch There is a bug in ToChildBlockJoinQuery that causes the score calculation to be skipped if the first child of a new parent doc is not in acceptDocs. I will attach test showing the failure and a patch to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Version field as DV
I think where Ishan is going with his question is this: 1. _version_ never needs to be searchable, thus, indexed=false makes sense. 2. _version_ typically needs to be evaluated with performing an update and, possibly, delete, thus stored=true makes sense. 3. _version_ would never be used for either sorting or faceting. 4. Given the above, is using docValues=true for _version_ a good idea? Looking at the documentation: https://cwiki.apache.org/confluence/display/solr/DocValues And a bit more background: http://lucidworks.com/blog/fun-with-docvalues-in-solr-4-2/ My take is a simple “no”. Since docValues is, in essence, column oriented storage (and can be seen, I think, as an alternate index format), what benefit is to be gained for the _version_ field. The primary benefits of docValues are in the sorting and faceting operations (maybe grouping?). These operations are never performed on the _version_ field, are they? I guess my remaining question is does it make sense to set indexed=”false” on _version_? The example schemas set indexed=true. Does solr itself perform searches internally on _version_? If so, then indexed=true is required. But otherwise, it seems like useless overhead. Note, I have been using optimistic concurrency control in one application and, so, am interested in this possible optimization. Any changes in this space between 4.x and 5.x? Thanks, Charlie From: Joel Bernstein [mailto:joels...@gmail.com] Sent: Monday, June 22, 2015 11:55 AM To: lucene dev Subject: Re: Version field as DV In general DocValues were built to support large scale random access use cases such as faceting and sorting. They have similar performance characteristics as the FieldCache. But unlike the FieldCache you can trade off memory and performance by selecting different DocValues formats. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 10:41 AM, Ishan Chattopadhyaya ichattopadhy...@gmail.commailto:ichattopadhy...@gmail.com wrote: Hi all, I am looking to try out _version_ as a docvalue (SOLR-6337) as a precursor to SOLR-5944. Towards that, I want the _version_ field to be stored=indexed=false, docValues=true. Does someone know about the performance implications of retrieving the _version_ as a docvalue, e.g. accessing docvalue vs. a stored field? Is there any known inefficiency when using a docvalue (as opposed to a stored field) due to random disk seeks, for example? Regards, Ishan * This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and then delete it. TIAA-CREF *
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12986 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12986/
Java: 64bit/jdk1.8.0_60-ea-b12 -XX:+UseCompressedOops -XX:+UseSerialGC
4 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterSSL
Error Message:
Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([BF7E0CE1F68C8BB6]:0)
at java.util.LinkedList$ListItr.next(LinkedList.java:893)
at
org.apache.solr.cloud.MiniSolrCloudCluster.shutdown(MiniSolrCloudCluster.java:349)
at
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.shutdown(TestMiniSolrCloudClusterSSL.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at java.lang.Thread.run(Thread.java:745)
FAILED:
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterSSL
Error Message:
94 threads leaked from SUITE scope at
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL: 1) Thread[id=1589,
name=zkCallback-176-thread-1, state=TIMED_WAITING,
group=TGRP-TestMiniSolrCloudClusterSSL] at sun.misc.Unsafe.park(Native
Method) at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)2) Thread[id=1543,
name=qtp405755026-1543-acceptor-0@31bbe4cc-ServerConnector@5afed860{HTTP/1.1}{127.0.0.1:57466},
state=RUNNABLE, group=TGRP-TestMiniSolrCloudClusterSSL] at
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
at
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:377)
at
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:500)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)3) Thread[id=1614,
name=Scheduler-148542929, state=TIMED_WAITING,
[jira] [Resolved] (SOLR-7502) start script should not try to create config set for .system collection
[
https://issues.apache.org/jira/browse/SOLR-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-7502.
--
Resolution: Fixed
Fix Version/s: 5.2
Trunk
start script should not try to create config set for .system collection
---
Key: SOLR-7502
URL: https://issues.apache.org/jira/browse/SOLR-7502
Project: Solr
Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: Trunk, 5.2
when I do {{bin/solr create -c .system}} it tries to upload the default
configset to ZK which fails the {{.system}} collection because it expects a
certain other configset
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7605) TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with redundent inner value
[
https://issues.apache.org/jira/browse/SOLR-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596137#comment-14596137
]
Steve Rowe commented on SOLR-7605:
--
It may be a different problem, but my Jenkins found a seed that reproducibly
causes TestCloudPivotFacet fails (Java8, branch_5x, LinuxOS X):
{noformat}
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCloudPivotFacet
-Dtests.method=test -Dtests.seed=2701C0115CD1BF95 -Dtests.slow=true
-Dtests.locale=ja_JP -Dtests.timezone=America/Scoresbysund -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 42.6s | TestCloudPivotFacet.test
[junit4] Throwable #1: java.lang.AssertionError:
{main(facet=truefacet.pivot=%7B%21stats%3Dst1%7Dpivot_y_s1%2Cdense_pivot_y_s%2Cdense_pivot_ti1facet.limit=9facet.sort=index),extra(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index)}
== Mean of sk1 = pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1:
{params(rows=0),defaults({main(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
expected:-1.4136202738271603E8 but was:-1.4136202738271606E8
[junit4]at
__randomizedtesting.SeedInfo.seed([2701C0115CD1BF95:AF55FFCBF22DD26D]:0)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:281)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] Caused by: java.lang.AssertionError: Mean of sk1 =
pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1:
{params(rows=0),defaults({main(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
expected:-1.4136202738271603E8 but was:-1.4136202738271606E8
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotStats(TestCloudPivotFacet.java:383)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotData(TestCloudPivotFacet.java:339)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:302)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:271)
[junit4]... 42 more
{noformat}
TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with
redundent inner value
---
Key: SOLR-7605
URL: https://issues.apache.org/jira/browse/SOLR-7605
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.3, Trunk
There have been two recent jenkins failures of TestCloudPivotFacet on both 5x
and trunk with the same underlying cause...
{noformat}
pProblem accessing /collection1/select. Reason:
prejava.lang.AssertionError: Must not add duplicate PivotFacetValue
with redundent inner value/pre/p
{noformat}
..digging through mail logs, it looks like there have been a handful of these
errors on different branches and os, with and w/o nightly, since April 1st of
this year.
The two recent seeds i tried (on trunk and 5x) reproduce - details to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7712) TestCloudPivotFacet failure
Steve Rowe created SOLR-7712:
Summary: TestCloudPivotFacet failure
Key: SOLR-7712
URL: https://issues.apache.org/jira/browse/SOLR-7712
Project: Solr
Issue Type: Bug
Affects Versions: 5.3
Reporter: Steve Rowe
Assignee: Hoss Man
java8, branch_5x trunk, r1686892
Original failure here (Linux):
http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/144/
Reproduces for me on OS X 10.10 on branch_5x, but on trunk failed to reproduce
the one time I tried it.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCloudPivotFacet
-Dtests.method=test -Dtests.seed=2701C0115CD1BF95 -Dtests.slow=true
-Dtests.locale=ja_JP -Dtests.timezone=America/Scoresbysund -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 42.6s | TestCloudPivotFacet.test
[junit4] Throwable #1: java.lang.AssertionError:
{main(facet=truefacet.pivot=%7B%21stats%3Dst1%7Dpivot_y_s1%2Cdense_pivot_y_s%2Cdense_pivot_ti1facet.limit=9facet.sort=index),extra(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index)}
== Mean of sk1 = pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1:
{params(rows=0),defaults({main(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
expected:-1.4136202738271603E8 but was:-1.4136202738271606E8
[junit4]at
__randomizedtesting.SeedInfo.seed([2701C0115CD1BF95:AF55FFCBF22DD26D]:0)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:281)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] Caused by: java.lang.AssertionError: Mean of sk1 =
pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1:
{params(rows=0),defaults({main(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
expected:-1.4136202738271603E8 but was:-1.4136202738271606E8
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotStats(TestCloudPivotFacet.java:383)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotData(TestCloudPivotFacet.java:339)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:302)
[junit4]at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:271)
[junit4]... 42 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper
[
https://issues.apache.org/jira/browse/SOLR-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Rajput updated SOLR-6736:
---
Attachment: test_pub.der
test_private.pem
newzkconf.zip
Hi [~noble.paul],
The three files, [ newzkconf.zip, test_private.pem, test_pub.der ] are zipped
into the zkconfighandler.zip which I had attached in my last comment. We need
to create a folder zkconfighandler under the test-files directory and put
these files under that location (solr/core/src/test-files/zkconfighandler).
I am attaching each of those 3 files individually here as well.
A collections-like request handler to manage solr configurations on zookeeper
-
Key: SOLR-6736
URL: https://issues.apache.org/jira/browse/SOLR-6736
Project: Solr
Issue Type: New Feature
Components: SolrCloud
Reporter: Varun Rajput
Assignee: Anshum Gupta
Priority: Minor
Fix For: 5.0, Trunk
Attachments: SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch,
SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, newzkconf.zip,
test_private.pem, test_pub.der, zkconfighandler.zip, zkconfighandler.zip
Managing Solr configuration files on zookeeper becomes cumbersome while using
solr in cloud mode, especially while trying out changes in the
configurations.
It will be great if there is a request handler that can provide an API to
manage the configurations similar to the collections handler that would allow
actions like uploading new configurations, linking them to a collection,
deleting configurations, etc.
example :
{code}
#use the following command to upload a new configset called mynewconf. This
will fail if there is alredy a conf called 'mynewconf'. The file could be a
jar , zip or a tar file which contains all the files for the this conf.
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@testconf.zip
http://localhost:8983/solr/admin/configs/mynewconf?sig=the-signature
{code}
A GET to http://localhost:8983/solr/admin/configs will give a list of configs
available
A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the
list of files in mynewconf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2396 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2396/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.mlt.CloudMLTQParserTest.test Error Message: java.lang.String cannot be cast to java.util.ArrayList Stack Trace: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.ArrayList at __randomizedtesting.SeedInfo.seed([B6FA7257A2556CC3:3EAE4D8D0CA9013B]:0) at org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:126) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11246 lines...] [junit4] Suite:
[jira] [Resolved] (SOLR-7544) Refactor and cleanup CollectionsHandler
[ https://issues.apache.org/jira/browse/SOLR-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-7544. -- Resolution: Fixed Fix Version/s: 5.2 Trunk bulk close Refactor and cleanup CollectionsHandler --- Key: SOLR-7544 URL: https://issues.apache.org/jira/browse/SOLR-7544 Project: Solr Issue Type: Task Reporter: Noble Paul Assignee: Noble Paul Fix For: Trunk, 5.2 Attachments: SOLR-7544.patch, SOLR-7544.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 13163 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13163/ Java: 64bit/jdk1.8.0_60-ea-b12 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:34189/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:34189/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([F60858ACBE254424:7E5C677610D929DC]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Commented] (SOLR-7605) TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with redundent inner value
[
https://issues.apache.org/jira/browse/SOLR-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596172#comment-14596172
]
Steve Rowe commented on SOLR-7605:
--
SOLR-7712
TestCloudPivotFacet failures: Must not add duplicate PivotFacetValue with
redundent inner value
---
Key: SOLR-7605
URL: https://issues.apache.org/jira/browse/SOLR-7605
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.3, Trunk
There have been two recent jenkins failures of TestCloudPivotFacet on both 5x
and trunk with the same underlying cause...
{noformat}
pProblem accessing /collection1/select. Reason:
prejava.lang.AssertionError: Must not add duplicate PivotFacetValue
with redundent inner value/pre/p
{noformat}
..digging through mail logs, it looks like there have been a handful of these
errors on different branches and os, with and w/o nightly, since April 1st of
this year.
The two recent seeds i tried (on trunk and 5x) reproduce - details to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Version field as DV
There is one advantage to setting DocValues=true, if the application frequently updates documents. Pulling this value from a DV will be faster than stored fields. The latter need to be decompressed, filter all but the _version_ field etc. indexed=true is only needed if Solr needs to know which document is associated with a certain version value. I don't know if it does though... Shai On Jun 22, 2015 7:23 PM, Reitzel, Charles charles.reit...@tiaa-cref.org wrote: I think where Ishan is going with his question is this: 1. _*version*_ never needs to be searchable, thus, indexed=false makes sense. 2. _*version*_ typically needs to be evaluated with performing an update and, possibly, delete, thus stored=true makes sense. 3. _*version*_ would never be used for either sorting or faceting. 4. Given the above, is using docValues=true for _*version*_ a good idea? Looking at the documentation: https://cwiki.apache.org/confluence/display/solr/DocValues And a bit more background: http://lucidworks.com/blog/fun-with-docvalues-in-solr-4-2/ My take is a simple “no”. Since docValues is, in essence, column oriented storage (and can be seen, I think, as an alternate index format), what benefit is to be gained for the _*version*_ field. The primary benefits of docValues are in the sorting and faceting operations (maybe grouping?). These operations are never performed on the _*version*_ field, are they? I guess my remaining question is does it make sense to set indexed=”false” on _*version*_? The example schemas set indexed=true. Does solr itself perform searches internally on _*version*_? If so, then indexed=true is required. But otherwise, it seems like useless overhead. Note, I have been using optimistic concurrency control in one application and, so, am interested in this possible optimization. Any changes in this space between 4.x and 5.x? Thanks, Charlie *From:* Joel Bernstein [mailto:joels...@gmail.com] *Sent:* Monday, June 22, 2015 11:55 AM *To:* lucene dev *Subject:* Re: Version field as DV In general DocValues were built to support large scale random access use cases such as faceting and sorting. They have similar performance characteristics as the FieldCache. But unlike the FieldCache you can trade off memory and performance by selecting different DocValues formats. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 10:41 AM, Ishan Chattopadhyaya ichattopadhy...@gmail.com wrote: Hi all, I am looking to try out _version_ as a docvalue (SOLR-6337) as a precursor to SOLR-5944. Towards that, I want the _version_ field to be stored=indexed=false, docValues=true. Does someone know about the performance implications of retrieving the _version_ as a docvalue, e.g. accessing docvalue vs. a stored field? Is there any known inefficiency when using a docvalue (as opposed to a stored field) due to random disk seeks, for example? Regards, Ishan * This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and then delete it. TIAA-CREF *
[jira] [Resolved] (SOLR-7662) Refactor the DocList writing to a common class
[ https://issues.apache.org/jira/browse/SOLR-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-7662. -- Resolution: Fixed Fix Version/s: Trunk 5.3 Refactor the DocList writing to a common class -- Key: SOLR-7662 URL: https://issues.apache.org/jira/browse/SOLR-7662 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Fix For: 5.3, Trunk Attachments: SOLR-7662.patch, SOLR-7662_5X.patch, SOLR-7662_5X.patch The code for streaming DocList is replicated in many response writers . Refactor it into a single place and re-use everywhere -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Version field as DV
2. _*version*_ typically needs to be evaluated with performing an update and, possibly, delete, thus stored=true makes sense. On Mon, Jun 22, 2015 at 9:53 PM, Reitzel, Charles charles.reit...@tiaa-cref.org wrote: I was looking at also making the stored=false along with docValues=true, since internally looking up a docvalue can be achieved using a value source (equivalent to field(_version_) as a function query) and the field doesn't need to stored. My main concern is the feasibility of doing that performance wise, and hence would it make sense for _version_ to go this way. Also, are there any benchmarks around accessing a stored value vs. accessing a docvalue? On Mon, Jun 22, 2015 at 9:53 PM, Reitzel, Charles charles.reit...@tiaa-cref.org wrote: I think where Ishan is going with his question is this: 1. _*version*_ never needs to be searchable, thus, indexed=false makes sense. 2. _*version*_ typically needs to be evaluated with performing an update and, possibly, delete, thus stored=true makes sense. 3. _*version*_ would never be used for either sorting or faceting. 4. Given the above, is using docValues=true for _*version*_ a good idea? Looking at the documentation: https://cwiki.apache.org/confluence/display/solr/DocValues And a bit more background: http://lucidworks.com/blog/fun-with-docvalues-in-solr-4-2/ My take is a simple “no”. Since docValues is, in essence, column oriented storage (and can be seen, I think, as an alternate index format), what benefit is to be gained for the _*version*_ field. The primary benefits of docValues are in the sorting and faceting operations (maybe grouping?). These operations are never performed on the _*version*_ field, are they? I guess my remaining question is does it make sense to set indexed=”false” on _*version*_? The example schemas set indexed=true. Does solr itself perform searches internally on _*version*_? If so, then indexed=true is required. But otherwise, it seems like useless overhead. Note, I have been using optimistic concurrency control in one application and, so, am interested in this possible optimization. Any changes in this space between 4.x and 5.x? Thanks, Charlie *From:* Joel Bernstein [mailto:joels...@gmail.com] *Sent:* Monday, June 22, 2015 11:55 AM *To:* lucene dev *Subject:* Re: Version field as DV In general DocValues were built to support large scale random access use cases such as faceting and sorting. They have similar performance characteristics as the FieldCache. But unlike the FieldCache you can trade off memory and performance by selecting different DocValues formats. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 10:41 AM, Ishan Chattopadhyaya ichattopadhy...@gmail.com wrote: Hi all, I am looking to try out _version_ as a docvalue (SOLR-6337) as a precursor to SOLR-5944. Towards that, I want the _version_ field to be stored=indexed=false, docValues=true. Does someone know about the performance implications of retrieving the _version_ as a docvalue, e.g. accessing docvalue vs. a stored field? Is there any known inefficiency when using a docvalue (as opposed to a stored field) due to random disk seeks, for example? Regards, Ishan * This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and then delete it. TIAA-CREF *
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2445 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2445/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([6681B14BF97D930:8E3C24CE116BB4C8]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.junit.Assert.assertNull(Assert.java:562) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:518) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:165) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
RE: Version field as DV
This thread kind of got off into a tangent about solr specifics -- if you skip down it's really a question about underlying performance concerns of using docvalues vs using stored fields. : 1. _version_ never needs to be searchable, thus, indexed=false makes sense. Unless i'm wrong, the version field is involved in search contexts because of optimistic concurrency - in order for an updated doc=1 if version=42 then under the covers a search is done against hte version field --- but since this is a fairly constrained filter, indexed=false might still be fine as long as docValues=true because the search can be done via a DocValues based filter. : 4. Given the above, is using docValues=true for _version_ a good idea? : My take is a simple “no”. Since docValues is, in essence, column : oriented storage (and can be seen, I think, as an alternate index : format), what benefit is to be gained for the _version_ field. The To be clear -- Solr already has code thta depends on having Doc Values on the version field to deal with max version value in segments (see VersionInfo.getVersionFromIndex and VersionInfo.getMaxVersionFromIndex) -- but as with any field, that doens't mean you must have 'docValues=true' in your schema, instead the UninvertedReader can be used as long as the field is indexed. But that's really not what Ishan is asking about. We know it's possible to use docValues=true indexed=false on the version field -- SOLR-6337 is open to decide if that makes sense in the sample configs. Ishan's question is really about stored=false. The key bit of context of Ishan's question is updateable docValues (SOLR-5944) and if/how it might be usable in Solr for the version field -- but one key aspect of doing that would be in ensuring that we can *return* the correct version value to user (for optimistic concurrency). Currently that's done with stored fields, but that wouldn't be feasible if we go down hte route of updateable docValues, which means we would have to return the version field from the docValues. that's where ishan's question about docvalues and performance and disk seeks comes from... What are the downsides in saying instead of using docvalues and stored fields for this this single valued int per doc, we're only going to use docvalues when doing pagination we will return the current value of the field to the user from the docvalues what kind of performance impacts come up in that case when you have 100 docs per page(ination) -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7711) tweak SearchHandler getDefaultComponents initial capacity
Christine Poerschke created SOLR-7711: - Summary: tweak SearchHandler getDefaultComponents initial capacity Key: SOLR-7711 URL: https://issues.apache.org/jira/browse/SOLR-7711 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Priority: Trivial github pull request to follow shortly, we now have 8 instead of 6 default components in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: SOLR-7711: tweak SearchHandler getDefaul...
GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/157 SOLR-7711: tweak SearchHandler getDefaultComponents initial capacity for https://issues.apache.org/jira/i#browse/SOLR-7711 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-SearchHandler-getDefaultComponents-tweak-initial-capacity Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/157.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #157 commit 0e518f15b546abd06542ae96ecd619cd5efc33dd Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2014-11-11T13:29:43Z SOLR-: tweak SearchHandler getDefaultComponents initial capacity (from 6 to 8) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7711) tweak SearchHandler getDefaultComponents initial capacity
[ https://issues.apache.org/jira/browse/SOLR-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596019#comment-14596019 ] ASF GitHub Bot commented on SOLR-7711: -- GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/157 SOLR-7711: tweak SearchHandler getDefaultComponents initial capacity for https://issues.apache.org/jira/i#browse/SOLR-7711 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-SearchHandler-getDefaultComponents-tweak-initial-capacity Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/157.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #157 commit 0e518f15b546abd06542ae96ecd619cd5efc33dd Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2014-11-11T13:29:43Z SOLR-: tweak SearchHandler getDefaultComponents initial capacity (from 6 to 8) tweak SearchHandler getDefaultComponents initial capacity - Key: SOLR-7711 URL: https://issues.apache.org/jira/browse/SOLR-7711 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Priority: Trivial github pull request to follow shortly, we now have 8 instead of 6 default components in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b12) - Build # 12987 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12987/
Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.cloud.HttpPartitionTest.test
Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms!
ClusterState: { collection1:{ replicationFactor:1, shards:{
shard1:{ range:8000-, state:active,
replicas:{core_node2:{ core:collection1,
base_url:http://127.0.0.1:60805/ba/cb;,
node_name:127.0.0.1:60805_ba%2Fcb, state:active,
leader:true}}}, shard2:{ range:0-7fff,
state:active, replicas:{ core_node1:{
core:collection1, base_url:http://127.0.0.1:49530/ba/cb;,
node_name:127.0.0.1:49530_ba%2Fcb, state:active,
leader:true}, core_node3:{
core:collection1, base_url:http://127.0.0.1:40990/ba/cb;,
node_name:127.0.0.1:40990_ba%2Fcb,
state:active, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false,
autoCreated:true}, control_collection:{ replicationFactor:1,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{core_node1:{
core:collection1, base_url:http://127.0.0.1:43695/ba/cb;,
node_name:127.0.0.1:43695_ba%2Fcb, state:active,
leader:true, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false,
autoCreated:true}, c8n_1x2:{ replicationFactor:2,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{ core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:43695/ba/cb;,
node_name:127.0.0.1:43695_ba%2Fcb, state:active,
leader:true}, core_node2:{
core:c8n_1x2_shard1_replica1,
base_url:http://127.0.0.1:49530/ba/cb;,
node_name:127.0.0.1:49530_ba%2Fcb, state:recovering,
router:{name:compositeId}, maxShardsPerNode:1,
autoAddReplicas:false}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 3 ms! ClusterState: {
collection1:{
replicationFactor:1,
shards:{
shard1:{
range:8000-,
state:active,
replicas:{core_node2:{
core:collection1,
base_url:http://127.0.0.1:60805/ba/cb;,
node_name:127.0.0.1:60805_ba%2Fcb,
state:active,
leader:true}}},
shard2:{
range:0-7fff,
state:active,
replicas:{
core_node1:{
core:collection1,
base_url:http://127.0.0.1:49530/ba/cb;,
node_name:127.0.0.1:49530_ba%2Fcb,
state:active,
leader:true},
core_node3:{
core:collection1,
base_url:http://127.0.0.1:40990/ba/cb;,
node_name:127.0.0.1:40990_ba%2Fcb,
state:active,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
control_collection:{
replicationFactor:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{core_node1:{
core:collection1,
base_url:http://127.0.0.1:43695/ba/cb;,
node_name:127.0.0.1:43695_ba%2Fcb,
state:active,
leader:true,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
c8n_1x2:{
replicationFactor:2,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:43695/ba/cb;,
node_name:127.0.0.1:43695_ba%2Fcb,
state:active,
leader:true},
core_node2:{
core:c8n_1x2_shard1_replica1,
base_url:http://127.0.0.1:49530/ba/cb;,
node_name:127.0.0.1:49530_ba%2Fcb,
state:recovering,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false}}
at
__randomizedtesting.SeedInfo.seed([6E705C26463D7974:E62463FCE8C1148C]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1842)
at
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:248)
at
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! On Mon, Jun 22, 2015 at 12:02 PM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Anshum Gupta
[jira] [Commented] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596524#comment-14596524
]
Erik Hatcher commented on SOLR-7276:
Another question - should we stick with $dollar-sign-prefixed values in the
expressions? It's dangerously close to the macro substitution feature that
uses ${curly-bracket-reference}. In these expressions the only non-operator
tokens will be parameter references, right? So maybe an expression could
simply be `fq={!bool}(foo OR bar) NOT baz` without dollar-signs?
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4830 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4830/ Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.mlt.CloudMLTQParserTest.test Error Message: java.lang.String cannot be cast to java.util.ArrayList Stack Trace: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.ArrayList at __randomizedtesting.SeedInfo.seed([3ACFB5254462174D:B29B8AFFEA9E7AB5]:0) at org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:126) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10198 lines...] [junit4] Suite:
[jira] [Updated] (SOLR-7651) Add a smile response writer
[
https://issues.apache.org/jira/browse/SOLR-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7651:
-
Attachment: SOLR-7651.patch
I plan to commit this shortly
Add a smile response writer
---
Key: SOLR-7651
URL: https://issues.apache.org/jira/browse/SOLR-7651
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: Perftest_SMILE.patch, SOLR-7651.patch, SOLR-7651.patch
The only binary option that we have today is {{javabin}} which has no other
language support other than Java
By adding smile , we get an equally efficient format which non-java languages
can leverage right away.
http://wiki.fasterxml.com/SmileFormat
payload size for a 10 document response are given below and it shows that it
is almost as frugal as javabin
{noformat}
javabin 2346
smile 2348
msgPack 3751
json 4549
bson 4854
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs
[ https://issues.apache.org/jira/browse/LUCENE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596057#comment-14596057 ] Christoph Kaser commented on LUCENE-6588: - Okay, if you prefer I can change the test to use a FilteredQuery instead of deleting child documents ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs - Key: LUCENE-6588 URL: https://issues.apache.org/jira/browse/LUCENE-6588 Project: Lucene - Core Issue Type: Bug Components: modules/join Affects Versions: 5.2.1 Reporter: Christoph Kaser Attachments: 0001-Test-score-calculation.patch, 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 0003-implements-ToChildBlockJoinQuery.explain.patch There is a bug in ToChildBlockJoinQuery that causes the score calculation to be skipped if the first child of a new parent doc is not in acceptDocs. I will attach test showing the failure and a patch to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! On Tue, Jun 23, 2015 at 12:32 AM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Thanks all! I've been using Solr in various capacities since 2008 and teaching training courses in it since 2010. I love the challenge that training brings, and the breadth of exposure to differing use-cases it brings [next course next week in London - do come!!] More recently I've been really enjoying the combination of bootstrap and AngularJS, and the way that I can (finally) do front end development. I hope to continue to bring that to Solr, with the new UI. There's so many ways it can better serve Solr users (and also be a better vehicle for training people too!) Many thanks for all your welcomes! Upayavira On Mon, Jun 22, 2015, at 05:14 PM, Shawn Heisey wrote: On 6/22/2015 1:02 PM, Steve Rowe wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Congratulations and welcome to the group! - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6755) ClassCastException from CloudMLTQParserTest
[
https://issues.apache.org/jira/browse/SOLR-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated SOLR-6755:
---
Attachment: SOLR-6755.patch
ClassCastException from CloudMLTQParserTest
---
Key: SOLR-6755
URL: https://issues.apache.org/jira/browse/SOLR-6755
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Anshum Gupta
Attachments: SOLR-6755.patch, SOLR-6755.patch
The seed doesn't reproduce for me, but the ClassCastException seems hinky and
worth looking into...
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CloudMLTQParserTest -Dtests.method=testDistribSearch
-Dtests.seed=3AE918BB008859A6 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=iw -Dtests.timezone=America/Indiana/Vincennes
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 50.7s J1 | CloudMLTQParserTest.testDistribSearch
[junit4] Throwable #1: java.lang.ClassCastException: java.lang.String
cannot be cast to java.util.ArrayList
[junit4] at
__randomizedtesting.SeedInfo.seed([3AE918BB008859A6:BB0F96A377D7399A]:0)
[junit4] at
org.apache.solr.search.mlt.CloudMLTQParserTest.doTest(CloudMLTQParserTest.java:124)
[junit4] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
[junit4] at java.lang.Thread.run(Thread.java:745)
{noformat}
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11466/consoleText
Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true)
At revision 1640267
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2446 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2446/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls Error Message: Shard split did not complete. Last recorded state: running expected:[completed] but was:[running] Stack Trace: org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: running expected:[completed] but was:[running] at __randomizedtesting.SeedInfo.seed([CCCFD55AAE74DB21:94AB593BA81E73F5]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Comment Edited] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596593#comment-14596593 ] Tim Allison edited comment on LUCENE-5205 at 6/22/15 8:29 PM: -- Cleaned up new lexer in lexer2 branch. Pre-release compiled jars are available [here|https://github.com/tballison/lucene-addons/releases/tag/5x-1.1] was (Author: talli...@mitre.org): Cleaned up new lexer in lexer2 branch. Prelease compiled jars are available [here|https://github.com/tballison/lucene-addons/releases/tag/5x-1.1] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596593#comment-14596593 ] Tim Allison commented on LUCENE-5205: - Cleaned up new lexer in lexer2 branch. Prelease compiled jars are available [here|https://github.com/tballison/lucene-addons/releases/tag/5x-1.1] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! On Tue, Jun 23, 2015 at 2:17 AM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Congrats Upayavira!! On Mon, Jun 22, 2015 at 1:10 PM, Joel Bernstein joels...@gmail.com wrote: Congrats Upayavira! Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 3:46 PM, Ramkumar R. Aiyengar andyetitmo...@gmail.com wrote: Welcome Upayavira! On 22 Jun 2015 20:02, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Varun Thacker
Re: Welcome Upayavira as Lucene/Solr committer
On 6/22/2015 1:02 PM, Steve Rowe wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Congratulations and welcome to the group! - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12989 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12989/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([F532E69E431BDFBA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10519 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2 Creating dataDir: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.HttpPartitionTest_F532E69E431BDFBA-001/init-core-data-001 [junit4] 2 723565 INFO (SUITE-HttpPartitionTest-seed#[F532E69E431BDFBA]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 723570 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 723577 INFO (Thread-1928) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 723577 INFO (Thread-1928) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 723677 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.ZkTestServer start zk server on port:54927 [junit4] 2 723678 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 723681 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 723688 INFO (zkCallback-475-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@7a9952fa name:ZooKeeperConnection Watcher:127.0.0.1:54927 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 723689 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 723689 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 723689 INFO (TEST-HttpPartitionTest.test-seed#[F532E69E431BDFBA]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2 723691 WARN
[jira] [Comment Edited] (SOLR-7554) Add checks in Streams for incoming stream order
[ https://issues.apache.org/jira/browse/SOLR-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596793#comment-14596793 ] Joel Bernstein edited comment on SOLR-7554 at 6/22/15 10:53 PM: Added tests that ensure the proper exception is being throw for the MergeStream, UniqueStream and ReducerStream. Didn't add the parallel tests yet as Exceptions are not being propagated from the workers yet. Those tests can be added in another ticket after exception propagation is put in place for parallel requests. was (Author: joel.bernstein): Add tests that ensure the proper exception is being throw for the MergeStream, UniqueStream and ReducerStream. Didn't add the parallel tests yet as Exceptions are not being propagated from the workers yet. Those tests can be added in another ticket after exception propagation is put in place for parallel requests. Add checks in Streams for incoming stream order --- Key: SOLR-7554 URL: https://issues.apache.org/jira/browse/SOLR-7554 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2, Trunk Reporter: Dennis Gove Priority: Minor Labels: streaming Fix For: 5.2, Trunk Attachments: SOLR-7554.patch, SOLR-7554.patch, SOLR-7554.patch Most Streams built on top of other streams require that their incoming stream(s) be ordered in a complimentary way to how this stream is expected to output its results. For example, if a MergeStream is merging two streams on fieldA asc, fieldB desc, then both its incoming streams must be ordered in a similar way. That said, the incoming stream could be ordered more strictly, ie fieldA asc, fieldB desc, fieldC asc but as long as the the comparator used in the MergeStream can be derived from the incoming stream's comparator then we are good to go. Some comparator A can be derived from some other comparator B iff the fields and their order in A is equal to the first fields and their order in B. For example, fieldA asc, fieldB dec can be derived from fieldA asc, fieldB desc, fieldC asc, fieldD asc but cannot be derived from field A asc. This patch is to add this validation support. It requires changes to Comparators, Equalitors, most Streams, and related tests. It adds a way to compare Comparators and Equalitors and in the end is one more required piece before we can add support for Join streams. It is dependent on SOLR-7513 and SOLR-7528. Other dependencies it has have already been committed to trunk and the 5.2 branch. It does not change any interfaces to code already released (5.1 and below). It does change interfaces to code in trunk and 5.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7712) TestCloudPivotFacet failure
[
https://issues.apache.org/jira/browse/SOLR-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596792#comment-14596792
]
Hoss Man commented on SOLR-7712:
TL;DR: I think this test needs some some small deltas when doing float/double
comparisons -- but i want to think about it a bit more.
FYI: I couldn't immediately reproduce that seed at r1686892 on 5x, the first
time i to beast it made it 5 iterations before it failed with the exact same
numeric values.
What this test is doing is executing a pivot fact request with stats enabled,
then executing a drill down queries on each pivot field value (by adding an
fq) and confirming the numResults matches the previously returned pivot count,
and that the top level stats of the drill down query equal the previously
returned per-pivot stats.
I remember when writing this test that i expected i would need to do some 3 arg
asserts on the floating point stat values to account for a small epsilon that
might be introduced in the floating point match because of the different order
of computation -- but when i ran the initial straw man test i never got any
errors.
I also remember working through the problem in my head for a few minutes to try
and figure out _why_ it wasn't failing -- and figuring that regardless of
whether it was top level stats or pivot stats, the same code was going to
accumulate the (per-index) values in the same order (the test doesn't do any
index updates concurrent to searching for obvious reasons) and i just left it
alone.
looking at these failures now, and adding some extra logging and thinking about
it a bit more, i think we've just been getting lucky that this hasn't failed
yet.
I can think of 2 ways for this type of validation to fail on exact floating
point comparison:
# _if_ different replicas get hit by the top level diff queries, _or_ a diff
replica was used to refine a pivot then is used by the verification query, and
_if_ those diff replicas have slightly diff segments (due ot recovery, or retry
or whatever so the accumulation of the sum of a field for all the matching
docs adds the numbers up in a diff order.
# if there are more then 2 shards, and the 2 top level queries (or the
refinement of a pivot query) gets responses from the shards in a diff order)
then the sum of the aggregate sum involves adding numbers in a diff order.
if the sum is diff, then the mean *might* be diff as well (depending on
precision loss due to dividing by the count)
But most times, we deal with numeric values that either don't lose precision
when added up, or lose precision the same amount in both ways.
TestCloudPivotFacet failure
---
Key: SOLR-7712
URL: https://issues.apache.org/jira/browse/SOLR-7712
Project: Solr
Issue Type: Bug
Affects Versions: 5.3
Reporter: Steve Rowe
Assignee: Hoss Man
java8, branch_5x trunk, r1686892
Original failure here (Linux):
http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/144/
Reproduces for me on OS X 10.10 on branch_5x, but on trunk failed to
reproduce the one time I tried it.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestCloudPivotFacet -Dtests.method=test
-Dtests.seed=2701C0115CD1BF95 -Dtests.slow=true -Dtests.locale=ja_JP
-Dtests.timezone=America/Scoresbysund -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 42.6s | TestCloudPivotFacet.test
[junit4] Throwable #1: java.lang.AssertionError:
{main(facet=truefacet.pivot=%7B%21stats%3Dst1%7Dpivot_y_s1%2Cdense_pivot_y_s%2Cdense_pivot_ti1facet.limit=9facet.sort=index),extra(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index)}
== Mean of sk1 = pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1:
{params(rows=0),defaults({main(rows=0q=id%3A%5B*+TO+304%5Dstats=truestats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_sstats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
expected:-1.4136202738271603E8 but was:-1.4136202738271606E8
[junit4] at
__randomizedtesting.SeedInfo.seed([2701C0115CD1BF95:AF55FFCBF22DD26D]:0)
[junit4] at
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:281)
[junit4] at
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
[junit4] at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
[junit4] at
[jira] [Updated] (SOLR-7554) Add checks in Streams for incoming stream order
[ https://issues.apache.org/jira/browse/SOLR-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-7554: - Attachment: SOLR-7554.patch Add tests that ensure the proper exception is being throw for the MergeStream, UniqueStream and ReducerStream. Didn't add the parallel tests yet as Exceptions are not being propagated from the workers yet. Those tests can be added in another ticket after exception propagation is put in place for parallel requests. Add checks in Streams for incoming stream order --- Key: SOLR-7554 URL: https://issues.apache.org/jira/browse/SOLR-7554 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2, Trunk Reporter: Dennis Gove Priority: Minor Labels: streaming Fix For: 5.2, Trunk Attachments: SOLR-7554.patch, SOLR-7554.patch, SOLR-7554.patch Most Streams built on top of other streams require that their incoming stream(s) be ordered in a complimentary way to how this stream is expected to output its results. For example, if a MergeStream is merging two streams on fieldA asc, fieldB desc, then both its incoming streams must be ordered in a similar way. That said, the incoming stream could be ordered more strictly, ie fieldA asc, fieldB desc, fieldC asc but as long as the the comparator used in the MergeStream can be derived from the incoming stream's comparator then we are good to go. Some comparator A can be derived from some other comparator B iff the fields and their order in A is equal to the first fields and their order in B. For example, fieldA asc, fieldB dec can be derived from fieldA asc, fieldB desc, fieldC asc, fieldD asc but cannot be derived from field A asc. This patch is to add this validation support. It requires changes to Comparators, Equalitors, most Streams, and related tests. It adds a way to compare Comparators and Equalitors and in the end is one more required piece before we can add support for Join streams. It is dependent on SOLR-7513 and SOLR-7528. Other dependencies it has have already been committed to trunk and the 5.2 branch. It does not change any interfaces to code already released (5.1 and below). It does change interfaces to code in trunk and 5.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! Koji On 2015/06/23 4:02, Steve Rowe wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - 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
Re: Welcome Upayavira as Lucene/Solr committer
Welcome, Upayavira! On Tue, Jun 23, 2015 at 3:02 AM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
[jira] [Commented] (LUCENE-6582) SynonymFilter should generate a correct (or, at least, better) graph
[
https://issues.apache.org/jira/browse/LUCENE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596804#comment-14596804
]
Robert Muir commented on LUCENE-6582:
-
Can we consider mike's crazy graph as a second step? I don't know, it just
seems like the current patch might be an easier-to-digest improvement. Then
again I get totally lost in the synonymfilter :)
There is a lot still to do after even this first step before users get real
improvements, for instance fixing querybuilder for the boolean case (hopefully
easier now), and improving stuff like sandbox/TermAutomatonQuery (maybe?) for
the positional case, and so on.
If we spend the work on a hypercorrect graph for synonymfilter I'm just afraid
of things getting lost, queryparser can't make use of it because posinc/poslen
semantics become too confusing, analysis is hard to reason about because
posinc/poslen semantics are too confusing, more performance tradeoffs (like
graph re-sausaging at index time), ...
SynonymFilter should generate a correct (or, at least, better) graph
Key: LUCENE-6582
URL: https://issues.apache.org/jira/browse/LUCENE-6582
Project: Lucene - Core
Issue Type: Bug
Reporter: Ian Ribas
Attachments: LUCENE-6582.patch, LUCENE-6582.patch, after.png,
after2.png, after3.png, before.png
Some time ago, I had a problem with synonyms and phrase type queries
(actually, it was elasticsearch and I was using a match query with multiple
terms and the and operator, as better explained here:
https://github.com/elastic/elasticsearch/issues/10394).
That issue led to some work on Lucene: LUCENE-6400 (where I helped a little
with tests) and LUCENE-6401. This issue is also related to LUCENE-3843.
Starting from the discussion on LUCENE-6400, I'm attempting to implement a
solution. Here is a patch with a first step - the implementation to fix
SynFilter to be able to 'make positions' (as was mentioned on the
[issue|https://issues.apache.org/jira/browse/LUCENE-6400?focusedCommentId=14498554page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498554]).
In this way, the synonym filter generates a correct (or, at least, better)
graph.
As the synonym matching is greedy, I only had to worry about fixing the
position length of the rules of the current match, no future or past synonyms
would span over this match (please correct me if I'm wrong!). It did
require more buffering, twice as much.
The new behavior I added is not active by default, a new parameter has to be
passed in a new constructor for {{SynonymFilter}}. The changes I made do
change the token stream generated by the synonym filter, and I thought it
would be better to let that be a voluntary decision for now.
I did some refactoring on the code, but mostly on what I had to change for
may implementation, so that the patch was not too hard to read. I created
specific unit tests for the new implementation
({{TestMultiWordSynonymFilter}}) that should show how things will be with the
new behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6595) CharFilter offsets correction is wonky
[
https://issues.apache.org/jira/browse/LUCENE-6595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596742#comment-14596742
]
Michael McCandless commented on LUCENE-6595:
Thanks [~caomanhdat], I'll try to understand your proposed change. But some
tests seem to be failing with this patch, e.g.:
{noformat}
[junit4] Suite: org.apache.lucene.analysis.core.TestBugInSomething
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestBugInSomething
-Dtests.method=test -Dtests.seed=FD8C8301DD07CEFD -Dtests.locale=hr
-Dtests.timezone=SystemV/PST8PDT -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.00s J2 | TestBugInSomething.test
[junit4] Throwable #1: java.lang.AssertionError: finalOffset
expected:16 but was:20
[junit4]at
__randomizedtesting.SeedInfo.seed([FD8C8301DD07CEFD:75D8BCDB73FBA305]:0)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:280)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:295)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:299)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:812)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:674)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:670)
[junit4]at
org.apache.lucene.analysis.core.TestBugInSomething.test(TestBugInSomething.java:77)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] IGNOR/A 0.01s J2 | TestBugInSomething.testUnicodeShinglesAndNgrams
[junit4] Assumption #1: 'slow' test group is disabled (@Slow())
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53): {},
docValues:{}, sim=DefaultSimilarity, locale=hr, timezone=SystemV/PST8PDT
[junit4] 2 NOTE: Linux 3.13.0-46-generic amd64/Oracle Corporation
1.8.0_40 (64-bit)/cpus=8,threads=1,free=370188896,total=519569408
{noformat}
and
{noformat}
[junit4] Suite:
org.apache.lucene.analysis.charfilter.TestHTMLStripCharFilterFactory
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestHTMLStripCharFilterFactory -Dtests.method=testSingleEscapedTag
-Dtests.seed=FD8C8301DD07CEFD -Dtests.locale=lt_LT
-Dtests.timezone=America/Thule -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.00s J3 |
TestHTMLStripCharFilterFactory.testSingleEscapedTag
[junit4] Throwable #1: java.lang.NullPointerException
[junit4]at
__randomizedtesting.SeedInfo.seed([FD8C8301DD07CEFD:36A72464D080D0F1]:0)
[junit4]at
org.apache.lucene.analysis.charfilter.BaseCharFilter.correctEnd(BaseCharFilter.java:82)
[junit4]at
org.apache.lucene.analysis.CharFilter.correctEndOffset(CharFilter.java:93)
[junit4]at
org.apache.lucene.analysis.Tokenizer.correctEndOffset(Tokenizer.java:84)
[junit4]at
org.apache.lucene.analysis.MockTokenizer.incrementToken(MockTokenizer.java:176)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:177)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:295)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:299)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:303)
[junit4]at
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:327)
[junit4]at
org.apache.lucene.analysis.charfilter.TestHTMLStripCharFilterFactory.testSingleEscapedTag(TestHTMLStripCharFilterFactory.java:99)
[junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}
CharFilter offsets correction is wonky
--
Key: LUCENE-6595
URL: https://issues.apache.org/jira/browse/LUCENE-6595
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Attachments: LUCENE-6595.patch
Spinoff from this original Elasticsearch issue:
https://github.com/elastic/elasticsearch/issues/11726
If I make a MappingCharFilter with these mappings:
{noformat}
( -
) -
{noformat}
i.e., just erase left and right paren, then tokenizing the string
(F31) with e.g. WhitespaceTokenizer,
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! On Mon, Jun 22, 2015 at 3:02 PM Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6582) SynonymFilter should generate a correct (or, at least, better) graph
[
https://issues.apache.org/jira/browse/LUCENE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596772#comment-14596772
]
Ian Ribas commented on LUCENE-6582:
---
Ok, I think I have an idea on how to do this, but it will definitely need some
thinking, so it will probably take a while.
bq. I think that's fine, I think better correctness trumps the added buffering
cost.
I completely agree.
bq. I think if we fix syn filter here to produce the correct graph, we should
also insert a sausagizer phase that turns this graph back into a sausage for
indexing?
I think Robert also commented something on these lines in his answer to my
email. I think I understand the general idea of what that means, but I would
certainly appreciate some guidance, when the time comes. I'll focus on
producing a correct graph first.
This also means that maybe I'll need changes on the test validations, since we
might run into conditions that are considered wrong now. Specially regarding
offsets (start and end) and their relation to position lengths. But I'll see
what I can do about that too.
bq. However, if you apply syn filter at search time, we could fix query parsers
to possibly do the right thing here
I was planning taking a shot at that too, once this part is finished. To make
the solution more complete. And, again, I'll certainly appreciate ideas when
the time comes.
SynonymFilter should generate a correct (or, at least, better) graph
Key: LUCENE-6582
URL: https://issues.apache.org/jira/browse/LUCENE-6582
Project: Lucene - Core
Issue Type: Bug
Reporter: Ian Ribas
Attachments: LUCENE-6582.patch, LUCENE-6582.patch, after.png,
after2.png, after3.png, before.png
Some time ago, I had a problem with synonyms and phrase type queries
(actually, it was elasticsearch and I was using a match query with multiple
terms and the and operator, as better explained here:
https://github.com/elastic/elasticsearch/issues/10394).
That issue led to some work on Lucene: LUCENE-6400 (where I helped a little
with tests) and LUCENE-6401. This issue is also related to LUCENE-3843.
Starting from the discussion on LUCENE-6400, I'm attempting to implement a
solution. Here is a patch with a first step - the implementation to fix
SynFilter to be able to 'make positions' (as was mentioned on the
[issue|https://issues.apache.org/jira/browse/LUCENE-6400?focusedCommentId=14498554page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498554]).
In this way, the synonym filter generates a correct (or, at least, better)
graph.
As the synonym matching is greedy, I only had to worry about fixing the
position length of the rules of the current match, no future or past synonyms
would span over this match (please correct me if I'm wrong!). It did
require more buffering, twice as much.
The new behavior I added is not active by default, a new parameter has to be
passed in a new constructor for {{SynonymFilter}}. The changes I made do
change the token stream generated by the synonym filter, and I thought it
would be better to let that be a voluntary decision for now.
I did some refactoring on the code, but mostly on what I had to change for
may implementation, so that the patch was not too hard to read. I created
specific unit tests for the new implementation
({{TestMultiWordSynonymFilter}}) that should show how things will be with the
new behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6598) `ant documentation-lint` fails on a checkout with spaces in it
Ramkumar Aiyengar created LUCENE-6598:
-
Summary: `ant documentation-lint` fails on a checkout with spaces
in it
Key: LUCENE-6598
URL: https://issues.apache.org/jira/browse/LUCENE-6598
Project: Lucene - Core
Issue Type: Bug
Reporter: Ramkumar Aiyengar
Priority: Minor
I haven't yet been able to figure out the cause here, but looks like
documentation-lint (and hence precommit) fails on a checkout with spaces in it..
Lots of errors due to checkJavadocLinks.py
{code}
...
[exec]
file:///home/ramkrithi/projects/lucene-solr/tr%20unk/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
...
{code}
The complaint is actually valid, notice the double escape in the URLs. This
seems to affect Solr documentation-lint (Lucene passes) because this problem
seems to occur only with the links Javadoc considers external (links from
Solr to Lucene) and hence puts the full path. Lucene links all have relative
paths which don't have this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6598) `ant documentation-lint` fails on a checkout with spaces in it
[
https://issues.apache.org/jira/browse/LUCENE-6598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596740#comment-14596740
]
Ramkumar Aiyengar commented on LUCENE-6598:
---
From the html:
{code}
$ less solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.html |
grep %2520
lia
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true
title=class or interface in
org.apache.lucene.queries.functionorg.apache.lucene.queries.function.ValueSource/a/li
td class=colOnecodespan class=memberNameLinka
href=../../../../../org/apache/solr/search/facet/SumAgg.html#SumAgg-org.apache.lucene.queries.function.ValueSource-SumAgg/a/span(a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true
title=class or interface in
org.apache.lucene.queries.functionValueSource/anbsp;vs)/codenbsp;/td
h3Methods inherited from classnbsp;org.apache.lucene.queries.function.a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true
title=class or interface in
org.apache.lucene.queries.functionValueSource/a/h3
codea
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true#createWeight-java.util.Map-org.apache.lucene.search.IndexSearcher-
title=class or interface in
org.apache.lucene.queries.functioncreateWeight/a, a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true#getSortField-boolean-
title=class or interface in
org.apache.lucene.queries.functiongetSortField/a, a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true#newContext-org.apache.lucene.search.IndexSearcher-
title=class or interface in
org.apache.lucene.queries.functionnewContext/a, a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true#toString--
title=class or interface in
org.apache.lucene.queries.functiontoString/a/code/li
prepublicnbsp;SumAgg(a
href=file:/home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html?is-external=true
title=class or interface in
org.apache.lucene.queries.functionValueSource/anbsp;vs)/pre
{code}
`ant documentation-lint` fails on a checkout with spaces in it
--
Key: LUCENE-6598
URL: https://issues.apache.org/jira/browse/LUCENE-6598
Project: Lucene - Core
Issue Type: Bug
Reporter: Ramkumar Aiyengar
Priority: Minor
I haven't yet been able to figure out the cause here, but looks like
documentation-lint (and hence precommit) fails on a checkout with spaces in
it..
Lots of errors due to checkJavadocLinks.py
{code}
...
[exec]
file:///home/ramkrithi/projects/lucene-solr/tr%20unk/solr/build/docs/solr-core/org/apache/solr/search/facet/SumAgg.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
[exec] BROKEN LINK:
file:///home/ramkrithi/projects/lucene-solr/tr%2520unk/lucene/build/docs/queries/org/apache/lucene/queries/function/ValueSource.html
...
{code}
The complaint is actually valid, notice the double escape in the URLs. This
seems to affect Solr documentation-lint (Lucene passes) because this problem
seems to occur only with the links Javadoc
[jira] [Comment Edited] (SOLR-7554) Add checks in Streams for incoming stream order
[ https://issues.apache.org/jira/browse/SOLR-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596793#comment-14596793 ] Joel Bernstein edited comment on SOLR-7554 at 6/22/15 10:54 PM: Added tests that ensure the proper exception is being thrown for the MergeStream, UniqueStream and ReducerStream. Didn't add the parallel tests yet as Exceptions are not being propagated from the workers yet. Those tests can be added in another ticket after exception propagation is put in place for parallel requests. was (Author: joel.bernstein): Added tests that ensure the proper exception is being throw for the MergeStream, UniqueStream and ReducerStream. Didn't add the parallel tests yet as Exceptions are not being propagated from the workers yet. Those tests can be added in another ticket after exception propagation is put in place for parallel requests. Add checks in Streams for incoming stream order --- Key: SOLR-7554 URL: https://issues.apache.org/jira/browse/SOLR-7554 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2, Trunk Reporter: Dennis Gove Priority: Minor Labels: streaming Fix For: 5.2, Trunk Attachments: SOLR-7554.patch, SOLR-7554.patch, SOLR-7554.patch Most Streams built on top of other streams require that their incoming stream(s) be ordered in a complimentary way to how this stream is expected to output its results. For example, if a MergeStream is merging two streams on fieldA asc, fieldB desc, then both its incoming streams must be ordered in a similar way. That said, the incoming stream could be ordered more strictly, ie fieldA asc, fieldB desc, fieldC asc but as long as the the comparator used in the MergeStream can be derived from the incoming stream's comparator then we are good to go. Some comparator A can be derived from some other comparator B iff the fields and their order in A is equal to the first fields and their order in B. For example, fieldA asc, fieldB dec can be derived from fieldA asc, fieldB desc, fieldC asc, fieldD asc but cannot be derived from field A asc. This patch is to add this validation support. It requires changes to Comparators, Equalitors, most Streams, and related tests. It adds a way to compare Comparators and Equalitors and in the end is one more required piece before we can add support for Join streams. It is dependent on SOLR-7513 and SOLR-7528. Other dependencies it has have already been committed to trunk and the 5.2 branch. It does not change any interfaces to code already released (5.1 and below). It does change interfaces to code in trunk and 5.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper
[
https://issues.apache.org/jira/browse/SOLR-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595440#comment-14595440
]
Noble Paul commented on SOLR-6736:
--
{noformat}
java.lang.RuntimeException: Cannot find resource in classpath or in file-system
(relative to CWD): zkconfighandler/test_pub.der
at
__randomizedtesting.SeedInfo.seed([9CC0E86607B4:14543F1A469A6A4C]:0)
at org.apache.solr.SolrTestCaseJ4.getFile(SolrTestCaseJ4.java:1763)
at
org.apache.solr.handler.admin.ZkConfigHandlerTest.readFile(ZkConfigHandlerTest.java:260)
at
org.apache.solr.handler.admin.ZkConfigHandlerTest.setupKeysInZk(ZkConfigHandlerTest.java:221)
at
org.apache.solr.handler.admin.ZkConfigHandlerTest.test(ZkConfigHandlerTest.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
where is the {{.DER}} file? {{.pem}} file does not work for java
A collections-like request handler to manage solr configurations on zookeeper
-
Key: SOLR-6736
URL: https://issues.apache.org/jira/browse/SOLR-6736
Project: Solr
Issue Type: New Feature
Components: SolrCloud
Reporter: Varun Rajput
Assignee: Anshum Gupta
Priority: Minor
Fix For: 5.0, Trunk
Attachments: SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch,
SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, zkconfighandler.zip,
zkconfighandler.zip
Managing Solr configuration files on zookeeper becomes cumbersome while using
solr in cloud mode, especially while trying out changes in the
configurations.
It will be great if there is a request handler that can provide an API to
manage the configurations similar to the collections handler that would allow
actions like uploading new configurations, linking them to a collection,
deleting configurations, etc.
example :
{code}
#use the following command to upload a new configset called mynewconf. This
will fail if there is alredy a conf called 'mynewconf'. The file could be a
jar , zip or a tar file which contains all the files for the this conf.
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@testconf.zip
http://localhost:8983/solr/admin/configs/mynewconf?sig=the-signature
{code}
A GET to http://localhost:8983/solr/admin/configs will give a list of configs
available
A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the
list of files in mynewconf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [CI] Lucene 5x Linux 64 Test Only - Build # 52424 - Failure!
I'm looking into it. On Mon, Jun 22, 2015 at 8:12 AM, bu...@elastic.co wrote: *BUILD FAILURE* Build URL http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/ Project:lucene_linux_java8_64_test_only Randomization: JDKEA9,local,heap[512m],-server +UseG1GC +UseCompressedOops,assert off,sec manager on Date of build:Mon, 22 Jun 2015 08:04:54 +0200 Build duration:7 min 44 sec *CHANGES* No Changes *BUILD ARTIFACTS* checkout/lucene/build/join/test/temp/junit4-J0-20150622_081228_876.events http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J0-20150622_081228_876.events checkout/lucene/build/join/test/temp/junit4-J1-20150622_081228_877.events http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J1-20150622_081228_877.events checkout/lucene/build/join/test/temp/junit4-J2-20150622_081228_877.events http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J2-20150622_081228_877.events checkout/lucene/build/join/test/temp/junit4-J3-20150622_081228_876.events http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J3-20150622_081228_876.events *FAILED JUNIT TESTS* Name: org.apache.lucene.search.join Failed: 1 test(s), Passed: 31 test(s), Skipped: 0 test(s), Total: 32 test(s) *Failed: org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq * *CONSOLE OUTPUT* [...truncated 9331 lines...] [junit4] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq [junit4] [junit4] [junit4] JVM J0: 0.56 .. 2.14 = 1.58s [junit4] JVM J1: 0.56 .. 4.36 = 3.80s [junit4] JVM J2: 0.56 .. 1.67 = 1.11s [junit4] JVM J3: 0.56 .. 4.86 = 4.30s [junit4] Execution time total: 4.86 sec. [junit4] Tests summary: 4 suites, 32 tests, 1 failure BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 4 suites, 32 tests, 1 failure Total time: 7 minutes 28 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDKEA9,local,heap[512m],-server +UseG1GC +UseCompressedOops,assert off,sec manager on Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien
[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595442#comment-14595442 ] Modassar Ather commented on LUCENE-5205: Adding one more test which will cause the issue. term1 any stop word E.g. plug in SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[CI] Lucene 5x Linux 64 Test Only - Build # 52424 - Failure!
BUILD FAILURE Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/ Project:lucene_linux_java8_64_test_only Randomization: JDKEA9,local,heap[512m],-server +UseG1GC +UseCompressedOops,assert off,sec manager on Date of build:Mon, 22 Jun 2015 08:04:54 +0200 Build duration:7 min 44 sec CHANGES No Changes BUILD ARTIFACTS checkout/lucene/build/join/test/temp/junit4-J0-20150622_081228_876.events checkout/lucene/build/join/test/temp/junit4-J1-20150622_081228_877.events checkout/lucene/build/join/test/temp/junit4-J2-20150622_081228_877.events checkout/lucene/build/join/test/temp/junit4-J3-20150622_081228_876.events FAILED JUNIT TESTS Name: org.apache.lucene.search.join Failed: 1 test(s), Passed: 31 test(s), Skipped: 0 test(s), Total: 32 test(s) Failed: org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq CONSOLE OUTPUT [...truncated 9331 lines...] [junit4] [junit4] [junit4] Tests with failures: [junit4] - org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq [junit4] [junit4] [junit4] JVM J0: 0.56 .. 2.14 = 1.58s [junit4] JVM J1: 0.56 .. 4.36 = 3.80s [junit4] JVM J2: 0.56 .. 1.67 = 1.11s [junit4] JVM J3: 0.56 .. 4.86 = 4.30s [junit4] Execution time total: 4.86 sec. [junit4] Tests summary: 4 suites, 32 tests, 1 failure BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 4 suites, 32 tests, 1 failure Total time: 7 minutes 28 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDKEA9,local,heap[512m],-server +UseG1GC +UseCompressedOops,assert off,sec manager on Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595763#comment-14595763 ] Tim Allison commented on LUCENE-5205: - Fixed in [solr-collab-5x branch|https://github.com/tballison/lucene-addons/tree/solr-collab-5x]. Over the next week, I hope to finish the implementation of the new lexer (get rid of the ugly regex) and do some general clean up. [~modassar], thank you for reporting this. Let me know if there are any other surprises. SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[CI] Lucene 5x Linux 64 Test Only - Build # 52449 - Failure!
BUILD FAILURE Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52449/ Project:lucene_linux_java8_64_test_only Randomization: JDKEA9,local,heap[1024m],-server +UseG1GC -UseCompressedOops Date of build:Mon, 22 Jun 2015 11:55:25 +0200 Build duration:2 hr 0 min CHANGES No Changes BUILD ARTIFACTS checkout/lucene/build/core/test/temp/junit4-J0-20150622_115547_580.events checkout/lucene/build/core/test/temp/junit4-J1-20150622_115547_583.events checkout/lucene/build/core/test/temp/junit4-J2-20150622_115547_583.events checkout/lucene/build/core/test/temp/junit4-J3-20150622_115547_583.events checkout/lucene/build/core/test/temp/junit4-J4-20150622_115547_580.events checkout/lucene/build/core/test/temp/junit4-J5-20150622_115547_583.events checkout/lucene/build/core/test/temp/junit4-J6-20150622_115547_580.events checkout/lucene/build/core/test/temp/junit4-J7-20150622_115547_583.events FAILED JUNIT TESTS Name: junit.framework Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s) Failed: junit.framework.TestSuite.org.apache.lucene.search.TestSameScoresWithThreads Name: org.apache.lucene.search Failed: 1 test(s), Passed: 781 test(s), Skipped: 2 test(s), Total: 784 test(s) Failed: org.apache.lucene.search.TestSameScoresWithThreads.test CONSOLE OUTPUT [...truncated 2034 lines...] [junit4] - org.apache.lucene.search.TestSameScoresWithThreads.test [junit4] - org.apache.lucene.search.TestSameScoresWithThreads (suite) [junit4] [junit4] [junit4] JVM J0: 1.20 .. 7231.52 = 7230.32s [junit4] JVM J1: 1.44 .. 139.88 = 138.43s [junit4] JVM J2: 1.20 .. 137.58 = 136.39s [junit4] JVM J3: 1.20 .. 141.00 = 139.81s [junit4] JVM J4: 1.20 .. 139.70 = 138.51s [junit4] JVM J5: 1.20 .. 138.23 = 137.03s [junit4] JVM J6: 1.20 .. 137.26 = 136.06s [junit4] JVM J7: 1.00 .. 138.37 = 137.37s [junit4] Execution time total: 2 hours 31 seconds [junit4] Tests summary: 401 suites, 3250 tests, 1 suite-level error, 1 error, 50 ignored (46 assumptions) BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 401 suites, 3250 tests, 1 suite-level error, 1 error, 50 ignored (46 assumptions) Total time: 120 minutes 41 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDKEA9,local,heap[1024m],-server +UseG1GC -UseCompressedOops Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs
[ https://issues.apache.org/jira/browse/LUCENE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595742#comment-14595742 ] Adrien Grand commented on LUCENE-6588: -- I don't think we should try to support fine-grained deletion of children documents. I would rather like blocks of documents to be not only added but also deleted atomically so that a parent and its children are either all live or all deleted. ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs - Key: LUCENE-6588 URL: https://issues.apache.org/jira/browse/LUCENE-6588 Project: Lucene - Core Issue Type: Bug Components: modules/join Affects Versions: 5.2.1 Reporter: Christoph Kaser Attachments: 0001-Test-score-calculation.patch, 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 0003-implements-ToChildBlockJoinQuery.explain.patch There is a bug in ToChildBlockJoinQuery that causes the score calculation to be skipped if the first child of a new parent doc is not in acceptDocs. I will attach test showing the failure and a patch to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs
[ https://issues.apache.org/jira/browse/LUCENE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595751#comment-14595751 ] Christoph Kaser commented on LUCENE-6588: - When I encountered this bug, there was no deleted document in the index - I think acceptDocs was set due to a filter. So the bug is relevant whether or not deleting single children is a supported use case. However, the easiest way to reproduce the bug was by deleting child documents, so that's what I used. ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs - Key: LUCENE-6588 URL: https://issues.apache.org/jira/browse/LUCENE-6588 Project: Lucene - Core Issue Type: Bug Components: modules/join Affects Versions: 5.2.1 Reporter: Christoph Kaser Attachments: 0001-Test-score-calculation.patch, 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 0003-implements-ToChildBlockJoinQuery.explain.patch There is a bug in ToChildBlockJoinQuery that causes the score calculation to be skipped if the first child of a new parent doc is not in acceptDocs. I will attach test showing the failure and a patch to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7709) JavaBinCodec
Dima Goldenberg created SOLR-7709: - Summary: JavaBinCodec Key: SOLR-7709 URL: https://issues.apache.org/jira/browse/SOLR-7709 Project: Solr Issue Type: Bug Reporter: Dima Goldenberg -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6585) Make ConjunctionDISI flatten sub ConjunctionDISI instances
[ https://issues.apache.org/jira/browse/LUCENE-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595771#comment-14595771 ] Paul Elschot commented on LUCENE-6585: -- Sorry about that. The patch has no recursion, and does not need it. Make ConjunctionDISI flatten sub ConjunctionDISI instances -- Key: LUCENE-6585 URL: https://issues.apache.org/jira/browse/LUCENE-6585 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6585.patch Today ConjunctionDISI wraps some sub (two-phase) iterators. I would like to improve it by flattening sub iterators when they implement ConjunctionDISI. In practice, this would make +A +(+B +C) be executed more like +A +B +C (only in terms of matching, scoring would not change). My motivation for this is that if we don't flatten and are unlucky, we can sometimes hit some worst cases. For instance consider the 3 following postings lists (sorted by increasing cost): A: 1, 1001, 2001, 3001, ... C: 0, 2, 4, 6, 8, 10, 12, 14, ... B: 1, 3, 5, 7, 9, 11, 13, 15, ... If we run +A +B +C, then everything works fine, we use A as a lead, and advance B 1000 by 1000 to find the next match (if any). However if we run +A +(+B +C), then we would iterate B and C 2 by 2 over the entire doc ID space when trying to find the first match which occurs on or after A:1. This is an extreme example which is unlikely to happen in practice, but flattening would also help a bit on some more common cases. For instance imagine that A, B and C have respective costs of 100, 10 and 1000. If you search for +A +(+B +C), then we will use the most costly iterator (C) to confirm matches of B (the least costly iterator, used as a lead) while it would have been more efficient to confirm matches of B with A first, since A is less costly than C. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException
Karl Wright created LUCENE-6597:
---
Summary: Geo3d circle creation that covers whole globe throws an
IllegalArgumentException
Key: LUCENE-6597
URL: https://issues.apache.org/jira/browse/LUCENE-6597
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: Karl Wright
The following GeoCircle construction:
{code}
new GeoCircle(PlanetModel.SPHERE, -20.0 * RADIANS_PER_DEGREE, -20.0 *
RADIANS_PER_DEGREE, Math.PI);
{code}
... fails as follows:
{code}
Degenerate/parallel vector constructed
{code}
The reason is that the plane normal vector cannot be computed in that case. A
special case is warranted for circles that cover the whole globe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7499) Deprecate the name parameter from the ADDREPLICA Collection API call
[ https://issues.apache.org/jira/browse/SOLR-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-7499: Fix Version/s: (was: 5.2) 5.3 Deprecate the name parameter from the ADDREPLICA Collection API call -- Key: SOLR-7499 URL: https://issues.apache.org/jira/browse/SOLR-7499 Project: Solr Issue Type: Bug Reporter: Varun Thacker Assignee: Varun Thacker Priority: Minor Fix For: 5.3, Trunk Attachments: SOLR-7499.patch, SOLR-7499.patch Right now we take a name parameter in the ADDREPLICA call. We use that as the core name for the replica. Are there any use cases where specifying the name of the core for the replica is useful? Here are the disadvantages of doing so - 1. We don't verify if the name is unique in the collection. So if a conflicting name ends up in the same node then the call will fail. 2. If it core is created on some other node, it will fail with legacyCloud=false as that checks for uniqueness in core names. https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica - The ref guide has never documented the name parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs
[ https://issues.apache.org/jira/browse/LUCENE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595768#comment-14595768 ] Adrien Grand commented on LUCENE-6588: -- OK I see, this was FilteredQuery using RANDOM_ACCESS_FILTER_STRATEGY to apply a filter as acceptDocs. ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs - Key: LUCENE-6588 URL: https://issues.apache.org/jira/browse/LUCENE-6588 Project: Lucene - Core Issue Type: Bug Components: modules/join Affects Versions: 5.2.1 Reporter: Christoph Kaser Attachments: 0001-Test-score-calculation.patch, 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 0003-implements-ToChildBlockJoinQuery.explain.patch There is a bug in ToChildBlockJoinQuery that causes the score calculation to be skipped if the first child of a new parent doc is not in acceptDocs. I will attach test showing the failure and a patch to fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595763#comment-14595763 ] Tim Allison edited comment on LUCENE-5205 at 6/22/15 11:04 AM: --- Fixed in [solr-collab-5x branch|https://github.com/tballison/lucene-addons/tree/solr-collab-5x]. Over the next week, I hope to finish the implementation of the new lexer (get rid of the ugly regex) and do some general clean up. [~modassar], thank you for reporting this. Let me know if there are any other surprises. Oh, and on your most recent post about the stopwords, y, that caused at least one unit test to blow up with 5.2.1. Thank you, again. was (Author: talli...@mitre.org): Fixed in [solr-collab-5x branch|https://github.com/tballison/lucene-addons/tree/solr-collab-5x]. Over the next week, I hope to finish the implementation of the new lexer (get rid of the ugly regex) and do some general clean up. [~modassar], thank you for reporting this. Let me know if there are any other surprises. SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To
[jira] [Commented] (LUCENE-6596) Make width of unordered near spans consistent with ordered
[ https://issues.apache.org/jira/browse/LUCENE-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595782#comment-14595782 ] Paul Elschot commented on LUCENE-6596: -- We could go further to account for nested holes. But for that I would rather have a float method like fuzzyFreq on Spans, and that brings more complications on how to score the nested spans. So for now I prefer to keep it simple, but consistent. Make width of unordered near spans consistent with ordered -- Key: LUCENE-6596 URL: https://issues.apache.org/jira/browse/LUCENE-6596 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: Trunk Reporter: Paul Elschot Priority: Minor Fix For: Trunk Attachments: LUCENE-6596.patch Use actual slop for width in NearSpansUnordered. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6596) Make width of unordered near spans consistent with ordered
[ https://issues.apache.org/jira/browse/LUCENE-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1459#comment-1459 ] Adrien Grand commented on LUCENE-6596: -- Thanks for the javadocs correction. +1 on making them more consistent, it also looks better to use the same formula to compute whether there is a match and the score. One thing I'm wondering about is if we should go even further and sum up the widths of the holes in-between consecutive spans? For instance, if I understand correctly, a SpanNearQuery over A, B, C in the following configuration would be considered a perfect match because of its total span length, even though it has holes: ||Sub span query||start pos||end pos|| |A|0|1| |B|10|20| |C|11|21| Make width of unordered near spans consistent with ordered -- Key: LUCENE-6596 URL: https://issues.apache.org/jira/browse/LUCENE-6596 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: Trunk Reporter: Paul Elschot Priority: Minor Fix For: Trunk Attachments: LUCENE-6596.patch Use actual slop for width in NearSpansUnordered. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6517) mockfilesystem tests fail with IBM jdk
[
https://issues.apache.org/jira/browse/LUCENE-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595577#comment-14595577
]
Brijesh Nekkare commented on LUCENE-6517:
-
The fix for this is currently undergoing the review process.
Brijesh Nekkare
IBM JRE team
mockfilesystem tests fail with IBM jdk
--
Key: LUCENE-6517
URL: https://issues.apache.org/jira/browse/LUCENE-6517
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Labels: IBM-J9
Test failures look like this:
{noformat}
[junit4] Suite: org.apache.lucene.mockfile.TestVerboseFS
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestVerboseFS
-Dtests.method=testURI -Dtests.seed=A5E55A5C894B6526 -Dtests.locale=lt_LT
-Dtests.timezone=America/Marigot -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.32s J1 | TestVerboseFS.testURI
[junit4] Throwable #1: java.lang.AssertionError:
expected:/home/rmuir/workspace/trunk-ibm/lucene/build/test-framework/test/J1/temp/lucene.mockfile.TestVerboseFS
A5E55A5C894B6526-001/tempDir-010/中国 but
was:/home/rmuir/workspace/trunk-ibm/lucene/build/test-framework/test/J1/temp/lucene.mockfile.TestVerboseFS
A5E55A5C894B6526-001/tempDir-010/-ý
[junit4] at
__randomizedtesting.SeedInfo.seed([A5E55A5C894B6526:2C5721F741543F17]:0)
[junit4] at
org.apache.lucene.mockfile.MockFileSystemTestCase.testURI(MockFileSystemTestCase.java:72)
[junit4] at java.lang.Thread.run(Thread.java:785)
[junit4] 2 NOTE: leaving temporary files on disk at:
/home/rmuir/workspace/trunk-ibm/lucene/build/test-framework/test/J1/temp/lucene.mockfile.TestVerboseFS
A5E55A5C894B6526-001
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene50): {},
docValues:{}, sim=RandomSimilarityProvider(queryNorm=true,coord=no): {},
locale=lt_LT, timezone=America/Marigot
[junit4] 2 NOTE: Linux 3.13.0-49-generic amd64/IBM Corporation 1.8.0
(64-bit)/cpus=8,threads=1,free=1578528,total=13041664
[junit4] 2 NOTE: All tests run in this JVM: [TestVerboseFS]
[junit4] Completed [4/36] on J1 in 0.97s, 14 tests, 1 failure FAILURES!
{noformat}
I think its a JDK bug. I've posted a small testcase here:
https://developer.ibm.com/answers/questions/194536/bug-in-pathtouri-with-the-default-filesystem-provi.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7708) Solr start/stop script is currently incompatible with Solaris (version 10)
Bence Vass created SOLR-7708: Summary: Solr start/stop script is currently incompatible with Solaris (version 10) Key: SOLR-7708 URL: https://issues.apache.org/jira/browse/SOLR-7708 Project: Solr Issue Type: Wish Affects Versions: 5.2.1, 5.2, 5.1, 5.0 Environment: Solaris 10 Reporter: Bence Vass Solr start/stop script is currently incompatible with Solaris (version 10) Main problems are: - use of lsof - options used on the ps command -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7499) Deprecate the name parameter from the ADDREPLICA Collection API call
[ https://issues.apache.org/jira/browse/SOLR-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-7499: Attachment: SOLR-7499.patch Updated patch to trunk. I'll commit this shortly Deprecate the name parameter from the ADDREPLICA Collection API call -- Key: SOLR-7499 URL: https://issues.apache.org/jira/browse/SOLR-7499 Project: Solr Issue Type: Bug Reporter: Varun Thacker Assignee: Varun Thacker Priority: Minor Fix For: 5.3, Trunk Attachments: SOLR-7499.patch, SOLR-7499.patch, SOLR-7499.patch Right now we take a name parameter in the ADDREPLICA call. We use that as the core name for the replica. Are there any use cases where specifying the name of the core for the replica is useful? Here are the disadvantages of doing so - 1. We don't verify if the name is unique in the collection. So if a conflicting name ends up in the same node then the call will fail. 2. If it core is created on some other node, it will fail with legacyCloud=false as that checks for uniqueness in core names. https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica - The ref guide has never documented the name parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6585) Make ConjunctionDISI flatten sub ConjunctionDISI instances
[ https://issues.apache.org/jira/browse/LUCENE-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595562#comment-14595562 ] Adrien Grand commented on LUCENE-6585: -- Paul, your comment confused me: where do you see recursion in the patch? Make ConjunctionDISI flatten sub ConjunctionDISI instances -- Key: LUCENE-6585 URL: https://issues.apache.org/jira/browse/LUCENE-6585 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6585.patch Today ConjunctionDISI wraps some sub (two-phase) iterators. I would like to improve it by flattening sub iterators when they implement ConjunctionDISI. In practice, this would make +A +(+B +C) be executed more like +A +B +C (only in terms of matching, scoring would not change). My motivation for this is that if we don't flatten and are unlucky, we can sometimes hit some worst cases. For instance consider the 3 following postings lists (sorted by increasing cost): A: 1, 1001, 2001, 3001, ... C: 0, 2, 4, 6, 8, 10, 12, 14, ... B: 1, 3, 5, 7, 9, 11, 13, 15, ... If we run +A +B +C, then everything works fine, we use A as a lead, and advance B 1000 by 1000 to find the next match (if any). However if we run +A +(+B +C), then we would iterate B and C 2 by 2 over the entire doc ID space when trying to find the first match which occurs on or after A:1. This is an extreme example which is unlikely to happen in practice, but flattening would also help a bit on some more common cases. For instance imagine that A, B and C have respective costs of 100, 10 and 1000. If you search for +A +(+B +C), then we will use the most costly iterator (C) to confirm matches of B (the least costly iterator, used as a lead) while it would have been more efficient to confirm matches of B with A first, since A is less costly than C. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6596) Make width of unordered near spans consistent with ordered
[ https://issues.apache.org/jira/browse/LUCENE-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595560#comment-14595560 ] Robert Muir commented on LUCENE-6596: - I do not think we should try to change the scoring by making it more fancy or complicated here. Instead it would be better to keep it simple and try to improve the performance of the spans without additional baggage. Make width of unordered near spans consistent with ordered -- Key: LUCENE-6596 URL: https://issues.apache.org/jira/browse/LUCENE-6596 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: Trunk Reporter: Paul Elschot Priority: Minor Fix For: Trunk Attachments: LUCENE-6596.patch Use actual slop for width in NearSpansUnordered. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [CI] Lucene 5x Linux 64 Test Only - Build # 52424 - Failure!
This failure is due to my fix to ToChildBlockJoinScorer, its advance code
now looks like:
@Override
public int advance(int childTarget) throws IOException {
if (childTarget = parentDoc) {
if (childTarget == NO_MORE_DOCS) {
return childDoc = parentDoc = NO_MORE_DOCS;
}
parentDoc = parentScorer.advance(childTarget + 1); // -- this is the
important part
}
[more stuff]
}
Now that we advance the parent scorer to childTarget+1 instead of
childTarget, the test does not work anymore since it relies on the
assumption that we will try to advance the parent scorer to childTarget. I
committed a change to the test that still allows it to check that
validation is performed. However I think it's putting too much pressure on
our queries to test that they fail if the index structure does not match
the parent query, maybe we should remove this test.
On Mon, Jun 22, 2015 at 9:04 AM, Adrien Grand jpou...@gmail.com wrote:
I'm looking into it.
On Mon, Jun 22, 2015 at 8:12 AM, bu...@elastic.co wrote:
*BUILD FAILURE*
Build URL
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/
Project:lucene_linux_java8_64_test_only Randomization:
JDKEA9,local,heap[512m],-server
+UseG1GC +UseCompressedOops,assert off,sec manager on Date of build:Mon,
22 Jun 2015 08:04:54 +0200 Build duration:7 min 44 sec
*CHANGES* No Changes
*BUILD ARTIFACTS*
checkout/lucene/build/join/test/temp/junit4-J0-20150622_081228_876.events
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J0-20150622_081228_876.events
checkout/lucene/build/join/test/temp/junit4-J1-20150622_081228_877.events
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J1-20150622_081228_877.events
checkout/lucene/build/join/test/temp/junit4-J2-20150622_081228_877.events
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J2-20150622_081228_877.events
checkout/lucene/build/join/test/temp/junit4-J3-20150622_081228_876.events
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52424/artifact/checkout/lucene/build/join/test/temp/junit4-J3-20150622_081228_876.events
*FAILED JUNIT TESTS* Name: org.apache.lucene.search.join Failed: 1
test(s), Passed: 31 test(s), Skipped: 0 test(s), Total: 32 test(s)
*Failed:
org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq
*
*CONSOLE OUTPUT* [...truncated 9331 lines...] [junit4] [junit4]
[junit4] Tests with failures: [junit4] -
org.apache.lucene.search.join.TestBlockJoinValidation.testAdvanceValidationForToChildBjq
[junit4]
[junit4] [junit4] JVM J0: 0.56 .. 2.14 = 1.58s [junit4] JVM J1: 0.56
.. 4.36 = 3.80s [junit4] JVM J2: 0.56 .. 1.67 = 1.11s [junit4] JVM J3:
0.56 .. 4.86 = 4.30s [junit4] Execution time total: 4.86 sec. [junit4]
Tests summary: 4 suites, 32 tests, 1 failure BUILD FAILED
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
There were test failures: 4 suites, 32 tests, 1 failure Total time: 7
minutes 28 seconds Build step 'Invoke Ant' marked build as failure Archiving
artifacts Recording test results [description-setter] Description set:
JDKEA9,local,heap[512m],-server +UseG1GC +UseCompressedOops,assert off,sec
manager on Email was triggered for: Failure - 1st Trigger Failure - Any
was overridden by another trigger and will not send an email. Trigger
Failure - Still was overridden by another trigger and will not send an
email. Sending email for trigger: Failure - 1st
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Adrien
--
Adrien
[jira] [Assigned] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues
[ https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira reassigned SOLR-7666: --- Assignee: Upayavira (was: Erick Erickson) Umbrella ticket for Angular JS post-5.2.1 issues Key: SOLR-7666 URL: https://issues.apache.org/jira/browse/SOLR-7666 Project: Solr Issue Type: New Feature Components: UI Affects Versions: 5.3, Trunk Reporter: Erick Erickson Assignee: Upayavira As of Solr 5.2.1, there's a new admin UI available that has been written almost entirely by Upayavira (thanks!) over the last several months. It's written in Angular JS with an eye towards enhancement/maintainability. The default UI is still the old version, but you can access the new version by going to http://sever:port/solr/index.html. There are a couple of fixes between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or 5.2.1 The expectation is that in Solr 5.3, the new code will become the default with the old UI deprecated and eventually removed. So it would be a great help if volunteers could give the new UI a spin. It should look much the same as the current one at the start, but evolve into something much more interesting and more cloud-friendly. Of course all the new UI code will always be available on trunk/6.0 too, and the up-to-date code will always be on both the trunk and 5x branches. Please provide feedback on the user's (or dev) lists about anything you find that doesn't work, or enhancements you'd like to see (or, even better, contribute). If you raise a JIRA, please link it to this one so I can keep track of what needs to be committed. If linking JIRAs is a mystery just add a comment to this JIRA referencing the new JIRA and we can take care of it. Please do _not_ attach patches to this JIRA, it'll be much easier to keep track of everything if the patches are attached to sub-JIRAs. And a big thanks to Upayavira for this work! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6521) org.apache.xerces.util is a protected pkg on IBM J9
[
https://issues.apache.org/jira/browse/LUCENE-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595574#comment-14595574
]
Brijesh Nekkare commented on LUCENE-6521:
-
I belong to IBM JRE team. Did the addition of permission resolve the issue.
org.apache.xerces.util is a protected pkg on IBM J9
---
Key: LUCENE-6521
URL: https://issues.apache.org/jira/browse/LUCENE-6521
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Labels: IBM-J9
Benchmarks tests fail like this currently, due to cyberneko evilness:
{noformat}
[junit4] ERROR 0.01s J2 | TestHtmlParser.testTitle
[junit4] Throwable #1: java.security.AccessControlException: Access
denied (java.lang.RuntimePermission
accessClassInPackage.org.apache.xerces.util)
[junit4] at
__randomizedtesting.SeedInfo.seed([7BEED366A25D3140:3F8A9D3571212953]:0)
[junit4] at
java.security.AccessController.throwACE(AccessController.java:157)
[junit4] at
java.security.AccessController.checkPermissionHelper(AccessController.java:216)
[junit4] at
java.security.AccessController.checkPermission(AccessController.java:263)
[junit4] at
java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
[junit4] at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1655)
[junit4] at java.lang.J9VMInternals$2.run(J9VMInternals.java:255)
[junit4] at
java.security.AccessController.doPrivileged(AccessController.java:529)
[junit4] at
java.lang.J9VMInternals.checkPackageAccess(J9VMInternals.java:253)
[junit4] at java.lang.ClassLoader.defineClassImpl(Native Method)
[junit4] at
java.lang.ClassLoader.defineClass(ClassLoader.java:345)
[junit4] at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:154)
[junit4] at
java.net.URLClassLoader.defineClass(URLClassLoader.java:727)
[junit4] at
java.net.URLClassLoader.access$400(URLClassLoader.java:95)
[junit4] at
java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1178)
[junit4] at
java.security.AccessController.doPrivileged(AccessController.java:595)
[junit4] at
java.net.URLClassLoader.findClass(URLClassLoader.java:602)
[junit4] at
java.lang.ClassLoader.loadClassHelper(ClassLoader.java:797)
[junit4] at java.lang.ClassLoader.loadClass(ClassLoader.java:771)
[junit4] at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:325)
[junit4] at java.lang.ClassLoader.loadClass(ClassLoader.java:752)
[junit4] at
org.cyberneko.html.parsers.SAXParser.init(SAXParser.java:38)
[junit4] at
org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser.init(DemoHTMLParser.java:55)
[junit4] at
org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser.init(DemoHTMLParser.java:51)
[junit4] at
org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser.testTitle(TestHtmlParser.java:89)
[junit4] at java.lang.Thread.run(Thread.java:785)
{noformat}
Root cause:
https://github.com/ecologylab/cyberneko/blob/master/src/org/cyberneko/html/HTMLConfiguration.java#L200-L206
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2444 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2444/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: JSONTupleStream: expected ARRAY_START but got EOF Stack Trace: java.io.IOException: JSONTupleStream: expected ARRAY_START but got EOF at __randomizedtesting.SeedInfo.seed([70EDAB0EE9248875:D7A913AA849F9BCC]:0) at org.apache.solr.client.solrj.io.stream.JSONTupleStream.expect(JSONTupleStream.java:99) at org.apache.solr.client.solrj.io.stream.JSONTupleStream.advanceToDocs(JSONTupleStream.java:159) at org.apache.solr.client.solrj.io.stream.JSONTupleStream.next(JSONTupleStream.java:77) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:148) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:833) at org.apache.solr.handler.TestSQLHandler.testTimeSeriesGrouping(TestSQLHandler.java:613) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
Committer review request
Hi, over the last two years or so, I created some JIRA issues with attached patches (mostly tiny bugfixes). I just looked through the list and there a some still open which were never reviewed, but the original issue still persists. As https://wiki.apache.org/lucene-java/HowToContribute tells me I should make a friendly reminder after a few days: Could somebody please look at those patches and apply them, if they are appropriate? LUCENE-4773: Bug in the modular query parser LUCENE-6358: Bug in the modular query parser LUCENE-6588: Bug in ToChildBlockJoinQuery (this one is not really old, but I mention it for completeness, and because it is a rather nasty bug) LUCENE-6586: Bug in GermanStemmer (already has a response, but I don't think it was committed) Obviously, the reason for those patches to be ignored may be that they don't conform to the code style or are incorrect (although I tried to take care to avoid that). If that is the case, I will of course fix them if somebody tells me the problem. Thank you! Best regards Christoph - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7499) Deprecate the name parameter from the ADDREPLICA Collection API call
[ https://issues.apache.org/jira/browse/SOLR-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595719#comment-14595719 ] ASF subversion and git services commented on SOLR-7499: --- Commit 1686827 from [~varunthacker] in branch 'dev/trunk' [ https://svn.apache.org/r1686827 ] SOLR-7499: Deprecate the 'name' parameter from the ADDREPLICA Collection API call Deprecate the name parameter from the ADDREPLICA Collection API call -- Key: SOLR-7499 URL: https://issues.apache.org/jira/browse/SOLR-7499 Project: Solr Issue Type: Bug Reporter: Varun Thacker Assignee: Varun Thacker Priority: Minor Fix For: 5.3, Trunk Attachments: SOLR-7499.patch, SOLR-7499.patch, SOLR-7499.patch Right now we take a name parameter in the ADDREPLICA call. We use that as the core name for the replica. Are there any use cases where specifying the name of the core for the replica is useful? Here are the disadvantages of doing so - 1. We don't verify if the name is unique in the collection. So if a conflicting name ends up in the same node then the call will fail. 2. If it core is created on some other node, it will fail with legacyCloud=false as that checks for uniqueness in core names. https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica - The ref guide has never documented the name parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4829 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4829/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.mlt.CloudMLTQParserTest.test Error Message: java.lang.String cannot be cast to java.util.ArrayList Stack Trace: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.ArrayList at __randomizedtesting.SeedInfo.seed([D5072ED3E409AC64:5D5311094AF5C19C]:0) at org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:126) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11286 lines...] [junit4] Suite:
[jira] [Commented] (LUCENE-6575) Improve API of PhraseQuery.Builder
[
https://issues.apache.org/jira/browse/LUCENE-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595565#comment-14595565
]
Adrien Grand commented on LUCENE-6575:
--
I am good with both options (new ClassName.Builder() vs. ClassName.builder()).
So given CustomAnalyzer already uses the static method approach with a
pkg-private constructor, I'm +1 on doing the same with queries for consistency.
Improve API of PhraseQuery.Builder
--
Key: LUCENE-6575
URL: https://issues.apache.org/jira/browse/LUCENE-6575
Project: Lucene - Core
Issue Type: Improvement
Reporter: Cao Manh Dat
Priority: Minor
Attachments: LUCENE-6575.patch, LUCENE-6575.patch, LUCENE-6575.patch,
LUCENE-6575.patch, LUCENE-6575.patch
From LUCENE-6531
In current PhraseQuery.Builder API. User must retype field again and again :
{code}
PhraseQuery.Builder builder = new PhraseQuery.Builder();
builder.add(new Term(lyrics, when), 1);
builder.add(new Term(lyrics, believe), 3);
{code}
Cleaner API :
{code}
PhraseQuery.Builder builder = new PhraseQuery.Builder(lyrics);
builder.add(when, 1);
builder.add(believe, 3);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12982 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12982/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.MultiThreadedOCPTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.MultiThreadedOCPTest: 1) Thread[id=891, name=OverseerThreadFactory-497-thread-5-processing-n:127.0.0.1:60306_, state=TIMED_WAITING, group=Overseer collection creation process.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerCollectionProcessor.waitForCoreNodeName(OverseerCollectionProcessor.java:1778) at org.apache.solr.cloud.OverseerCollectionProcessor.splitShard(OverseerCollectionProcessor.java:1668) at org.apache.solr.cloud.OverseerCollectionProcessor.processMessage(OverseerCollectionProcessor.java:596) at org.apache.solr.cloud.OverseerCollectionProcessor$Runner.run(OverseerCollectionProcessor.java:2844) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:156) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.MultiThreadedOCPTest: 1) Thread[id=891, name=OverseerThreadFactory-497-thread-5-processing-n:127.0.0.1:60306_, state=TIMED_WAITING, group=Overseer collection creation process.] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.OverseerCollectionProcessor.waitForCoreNodeName(OverseerCollectionProcessor.java:1778) at org.apache.solr.cloud.OverseerCollectionProcessor.splitShard(OverseerCollectionProcessor.java:1668) at org.apache.solr.cloud.OverseerCollectionProcessor.processMessage(OverseerCollectionProcessor.java:596) at org.apache.solr.cloud.OverseerCollectionProcessor$Runner.run(OverseerCollectionProcessor.java:2844) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:156) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([F92C099CFE2373C3]:0) FAILED: org.apache.solr.search.mlt.CloudMLTQParserTest.test Error Message: java.lang.String cannot be cast to java.util.ArrayList Stack Trace: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.ArrayList at __randomizedtesting.SeedInfo.seed([F92C099CFE2373C3:7178364650DF1E3B]:0) at org.apache.solr.search.mlt.CloudMLTQParserTest.test(CloudMLTQParserTest.java:126) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
Welcome Upayavira as Lucene/Solr committer
I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596524#comment-14596524
]
Erik Hatcher edited comment on SOLR-7276 at 6/22/15 7:41 PM:
-
Another question - should we stick with $dollar-sign-prefixed values in the
expressions? It's dangerously close to the macro substitution feature that
uses $\{curly-bracket-reference}. In these expressions the only non-operator
tokens will be parameter references, right? So maybe an expression could
simply be `fq=\{!bool}(foo OR bar) NOT baz` without dollar-signs?
was (Author: ehatcher):
Another question - should we stick with $dollar-sign-prefixed values in the
expressions? It's dangerously close to the macro substitution feature that
uses ${curly-bracket-reference}. In these expressions the only non-operator
tokens will be parameter references, right? So maybe an expression could
simply be `fq={!bool}(foo OR bar) NOT baz` without dollar-signs?
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Congrats Upayavira!! On Mon, Jun 22, 2015 at 1:10 PM, Joel Bernstein joels...@gmail.com wrote: Congrats Upayavira! Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 3:46 PM, Ramkumar R. Aiyengar andyetitmo...@gmail.com wrote: Welcome Upayavira! On 22 Jun 2015 20:02, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! Glad to have you on board. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Monday, June 22, 2015 3:03 PM To: lucene dev Subject: Welcome Upayavira as Lucene/Solr committer I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - 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
Re: Welcome Upayavira as Lucene/Solr committer
Welcome, Upayavira! Dawid On Mon, Jun 22, 2015 at 9:02 PM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - 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
Re: Welcome Upayavira as Lucene/Solr committer
Congrats Upayavira! -Yonik On Mon, Jun 22, 2015 at 3:02 PM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6582) SynonymFilter should generate a correct (or, at least, better) graph
[
https://issues.apache.org/jira/browse/LUCENE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596490#comment-14596490
]
Michael McCandless commented on LUCENE-6582:
bq. I really hadn't thought of using position lengths as references, like
this!
It's hard to think about :) But it just means the positions become node IDs,
and you must number the nodes properly (so that any token always goes from
node X to Y where Y X).
bq. One problem that I see is that I'll need more buffering
I think that's fine, I think better correctness trumps the added buffering cost.
bq. One other doubt I have is how this affects the indexer. I imagine it saves
position lengths on the index too, so this shouldn't be a problem, right?
The index does NOT record position length today... I think if we fix syn filter
here to produce the correct graph, we should also insert a sausagizer phase
that turns this graph back into a sausage for indexing? (So that what the
fudge and wow that's funny will in fact match a document that had wtf).
However, if you apply syn filter at search time, we could fix query parsers to
possibly do the right thing here, e.g. translating this graph into a union of
phrase queries, or using TermAutomatonQuery (in sandbox still), or something ...
SynonymFilter should generate a correct (or, at least, better) graph
Key: LUCENE-6582
URL: https://issues.apache.org/jira/browse/LUCENE-6582
Project: Lucene - Core
Issue Type: Bug
Reporter: Ian Ribas
Attachments: LUCENE-6582.patch, LUCENE-6582.patch, after.png,
after2.png, after3.png, before.png
Some time ago, I had a problem with synonyms and phrase type queries
(actually, it was elasticsearch and I was using a match query with multiple
terms and the and operator, as better explained here:
https://github.com/elastic/elasticsearch/issues/10394).
That issue led to some work on Lucene: LUCENE-6400 (where I helped a little
with tests) and LUCENE-6401. This issue is also related to LUCENE-3843.
Starting from the discussion on LUCENE-6400, I'm attempting to implement a
solution. Here is a patch with a first step - the implementation to fix
SynFilter to be able to 'make positions' (as was mentioned on the
[issue|https://issues.apache.org/jira/browse/LUCENE-6400?focusedCommentId=14498554page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498554]).
In this way, the synonym filter generates a correct (or, at least, better)
graph.
As the synonym matching is greedy, I only had to worry about fixing the
position length of the rules of the current match, no future or past synonyms
would span over this match (please correct me if I'm wrong!). It did
require more buffering, twice as much.
The new behavior I added is not active by default, a new parameter has to be
passed in a new constructor for {{SynonymFilter}}. The changes I made do
change the token stream generated by the synonym filter, and I thought it
would be better to let that be a voluntary decision for now.
I did some refactoring on the code, but mostly on what I had to change for
may implementation, so that the patch was not too hard to read. I created
specific unit tests for the new implementation
({{TestMultiWordSynonymFilter}}) that should show how things will be with the
new behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-7276:
---
Fix Version/s: Trunk
5.3
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Assignee: Erik Hatcher
Fix For: 5.3, Trunk
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher reassigned SOLR-7276:
--
Assignee: Erik Hatcher
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Assignee: Erik Hatcher
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6582) SynonymFilter should generate a correct (or, at least, better) graph
[
https://issues.apache.org/jira/browse/LUCENE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596318#comment-14596318
]
Ian Ribas commented on LUCENE-6582:
---
I really hadn't thought of using position lengths as references, like this!
For some reason I could only think of position length spanning over terms on
the base stream, not creating independent branches. And so I was stuck in
thinking how to represent the graph correctly once I saw that my
implementation was still a sausage on the overlapping phrases.
I will try to implement this solution and see how far I can get.
One problem that I see is that I'll need more buffering as now the future
output is no longer the size of the longest synonym but the added sizes of all
synonyms that are phrases (each minus one). Getting this number at the
beginning might require a change on the synonym parser...
One other doubt I have is how this affects the indexer. I imagine it saves
position lengths on the index too, so this shouldn't be a problem, right?
Thanks very much for such clear guidelines!
SynonymFilter should generate a correct (or, at least, better) graph
Key: LUCENE-6582
URL: https://issues.apache.org/jira/browse/LUCENE-6582
Project: Lucene - Core
Issue Type: Bug
Reporter: Ian Ribas
Attachments: LUCENE-6582.patch, LUCENE-6582.patch, after.png,
after2.png, after3.png, before.png
Some time ago, I had a problem with synonyms and phrase type queries
(actually, it was elasticsearch and I was using a match query with multiple
terms and the and operator, as better explained here:
https://github.com/elastic/elasticsearch/issues/10394).
That issue led to some work on Lucene: LUCENE-6400 (where I helped a little
with tests) and LUCENE-6401. This issue is also related to LUCENE-3843.
Starting from the discussion on LUCENE-6400, I'm attempting to implement a
solution. Here is a patch with a first step - the implementation to fix
SynFilter to be able to 'make positions' (as was mentioned on the
[issue|https://issues.apache.org/jira/browse/LUCENE-6400?focusedCommentId=14498554page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498554]).
In this way, the synonym filter generates a correct (or, at least, better)
graph.
As the synonym matching is greedy, I only had to worry about fixing the
position length of the rules of the current match, no future or past synonyms
would span over this match (please correct me if I'm wrong!). It did
require more buffering, twice as much.
The new behavior I added is not active by default, a new parameter has to be
passed in a new constructor for {{SynonymFilter}}. The changes I made do
change the token stream generated by the synonym filter, and I thought it
would be better to let that be a voluntary decision for now.
I did some refactoring on the code, but mostly on what I had to change for
may implementation, so that the patch was not too hard to read. I created
specific unit tests for the new implementation
({{TestMultiWordSynonymFilter}}) that should show how things will be with the
new behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! On 22 Jun 2015 20:02, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596517#comment-14596517
]
Erik Hatcher commented on SOLR-7276:
Question, in #shouldCollect(), should it really default to returning true if
there is an illegal operator encountered? Seems like false should be the
default action (though arguably it can't get to this part of the code anyway):
{code}
LOG.debug( shouldn't get here! returning true );
return true;
{code}
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Welcome Upayavira! Mike McCandless http://blog.mikemccandless.com On Mon, Jun 22, 2015 at 3:02 PM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - 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
Solr query sizing
Hi, Is it possible to get an estimate of size of all documents that match a specific search query in Solr? If not - is it feasible to add such support? Regards Hrishikesh
[jira] [Updated] (SOLR-7276) Add a Boolean Post Filter QParserPlugin
[
https://issues.apache.org/jira/browse/SOLR-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-7276:
---
Attachment: SOLR-7276.patch
Here's a new patch that changes a few things:
* instead of local `expr` parameter for {!bool}, switched to `v` so that the
expression can work outside the curly brackets as `{!bool}expression`
* Added throwing of SolrException in createParser rather than returning null
when there's an error
* Trimmed a bunch of unnecessary stuff from the test solrconfig
Add a Boolean Post Filter QParserPlugin
---
Key: SOLR-7276
URL: https://issues.apache.org/jira/browse/SOLR-7276
Project: Solr
Issue Type: New Feature
Reporter: Ted Sullivan
Attachments: SOLR-7276.patch, SOLR-7276.patch
This plugin enables existing post filter implementations to be combined using
Boolean logic. It works by building a parse tree of referenced Post
Filters. When a document is sent to the collect( ) method of the
BooleanPostFilter, it is sent to all of the delegates that point to a local
Collector that sets a flag if the DelegatingCollector calls its collect
method. After all of the delegates have been polled, the parse tree output
determines if the document should be ultimately collected.
The syntax for the post filter is like this:
{noformat}
fq={!bool expr=(($foo OR $bar) NOT $baz)}foo={!foo ...}bar={!bar ...
}baz={!baz ...}
{noformat}
Where foo, bar and baz are all post filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Congrats Upayavira! Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Jun 22, 2015 at 3:46 PM, Ramkumar R. Aiyengar andyetitmo...@gmail.com wrote: Welcome Upayavira! On 22 Jun 2015 20:02, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Upayavira as Lucene/Solr committer
Congratulations, Upayavira! On Jun 23, 2015, at 4:02 AM, Steve Rowe sar...@gmail.com wrote: I'm pleased to announce that Upayavira has accepted the PMC's invitation to become a committer. Upayavira, it's tradition that you introduce yourself with a brief bio. Mike McCandless, the Lucene PMC chair, has already added your “upayavira account to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597157#comment-14597157 ] Modassar Ather commented on LUCENE-5205: Hi [~talli...@mitre.org] Did you mean the fix for the failing query with exception (Less than 2 subSpans.size() : 1) ? SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 12993 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12993/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.DeleteInactiveReplicaTest.deleteInactiveReplicaTest Error Message: Server refused connection at: http://127.0.0.1:35182 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Server refused connection at: http://127.0.0.1:35182 at __randomizedtesting.SeedInfo.seed([8AAFDA3E1DAADB5E:479141CD520BADBC]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:568) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.DeleteInactiveReplicaTest.deleteInactiveReplicaTest(DeleteInactiveReplicaTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Created] (LUCENE-6599) TestUninvertingReader NPE
Steve Rowe created LUCENE-6599:
--
Summary: TestUninvertingReader NPE
Key: LUCENE-6599
URL: https://issues.apache.org/jira/browse/LUCENE-6599
Project: Lucene - Core
Issue Type: Bug
Components: modules/other
Affects Versions: 5.3
Reporter: Steve Rowe
Reproduces for me.
{noformat}
[junit4] Suite: org.apache.lucene.uninverting.TestUninvertingReader
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestUninvertingReader -Dtests.method=testSortedSetIntegerManyValues
-Dtests.seed=D1F0E8CD6B84BE29 -Dtests.slow=true -Dtests.locale=ar_BH
-Dtests.timezone=America/North_Dakota/New_Salem -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 1.26s |
TestUninvertingReader.testSortedSetIntegerManyValues
[junit4] Throwable #1: java.lang.NullPointerException
[junit4]at
__randomizedtesting.SeedInfo.seed([D1F0E8CD6B84BE29:302C59F0FE05336F]:0)
[junit4]at
org.apache.lucene.uninverting.TestUninvertingReader.testSortedSetIntegerManyValues(TestUninvertingReader.java:277)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{trie_single=FSTOrd50, trie_multi=BlockTreeOrds(blocksize=128),
notrie_multi=FST50, notrie_single=BlockTreeOrds(blocksize=128)}, docValues:{},
sim=DefaultSimilarity, locale=ar_BH, timezone=America/North_Dakota/New_Salem
[junit4] 2 NOTE: Mac OS X 10.10.3 x86_64/Oracle Corporation 1.7.0_71
(64-bit)/cpus=8,threads=1,free=211776016,total=257425408
{noformat}
Original failure here:
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java7/395/]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7709) Solr JavaBinCodec multi valued fields take only the last value per document from the javabin buffer
[ https://issues.apache.org/jira/browse/SOLR-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dima Goldenberg updated SOLR-7709: -- Component/s: contrib - DataImportHandler Description: when sending a javabin document to solr in the following format ... ... filed_2 value_1 field_2 value_2 field_2 value_3 ... ... field_2 will get the last value (field_2 = [value_3, ]). using the xml instead the javabin: field_2 will get the all the values (field_2 = [value_1, value_2, value_3, ]). the problem is in: JavaBinCodec::readSolrDocument JavaBinCodec::readSolrInputDocument instead the SolrInputDocument::setField function we should use SolrInputDocument::addField function. i use the 4.8.1 solr version but i pretty sure this issue is reproducible using older versions. Affects Version/s: 4.8.1 Summary: Solr JavaBinCodec multi valued fields take only the last value per document from the javabin buffer (was: JavaBinCodec) Solr JavaBinCodec multi valued fields take only the last value per document from the javabin buffer --- Key: SOLR-7709 URL: https://issues.apache.org/jira/browse/SOLR-7709 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.8.1 Reporter: Dima Goldenberg when sending a javabin document to solr in the following format ... ... filed_2 value_1 field_2 value_2 field_2 value_3 ... ... field_2 will get the last value (field_2 = [value_3, ]). using the xml instead the javabin: field_2 will get the all the values (field_2 = [value_1, value_2, value_3, ]). the problem is in: JavaBinCodec::readSolrDocument JavaBinCodec::readSolrInputDocument instead the SolrInputDocument::setField function we should use SolrInputDocument::addField function. i use the 4.8.1 solr version but i pretty sure this issue is reproducible using older versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
