[jira] [Commented] (LUCENE-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException
[
https://issues.apache.org/jira/browse/LUCENE-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600824#comment-14600824
]
Karl Wright commented on LUCENE-6597:
-
Also, David, this particular patch is *not* rocket science IMHO. It just
corrects a case I broke with WGS84, which a test suite a work caught. If you
want to *extend* the functionality, really we should be talking about another
ticket.
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
Attachments: LUCENE-6597.patch
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] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600831#comment-14600831 ] Karl Wright commented on LUCENE-6578: - bq. For example I see the same method with method calls changed from normalDistance to normalDistanceSquared but otherwise appears identical. Can you please think of a way to approach this with less repetition and thus more maintainability? The whole purpose of having multiple distance metrics is performance. These computations are expected to be used at document scoring time. Saving even a single expensive sqrt is important in that context, which is why the implementations look as they do. Object creation for the purposes of reducing code duplication according to pattern is also a bad idea for the same reason. Object creation would be required for any kind of more complete code-sharing approach. Mapping the xxx(GeoPoint pt) to xxx(x,y,z), though, is something doable and I will look into it. I will also remove the javadoc, although I find it odd that that would be considered important for Lucene. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-Tests-5.x-Java7 - Build # 3260 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3260/ 1 tests failed. FAILED: org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([66FF68CB21571533:319D12E2088644B9]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737) at org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer(TestCustomDocTransformer.java:67) 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 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) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//str[.='xx#title_0#'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime0/int/lstresult name=response numFound=10 start=0docint name=id0/intarr
[jira] [Commented] (LUCENE-6610) Potential resource leak in WordDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601816#comment-14601816 ] ASF GitHub Bot commented on LUCENE-6610: GitHub user rmp91 opened a pull request: https://github.com/apache/lucene-solr/pull/162 LUCENE-6610:Fixed potential resource leaks https://issues.apache.org/jira/browse/LUCENE-6610 You can merge this pull request into a Git repository by running: $ git pull https://github.com/rmp91/lucene-solr LUCENE-6610 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/162.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 #162 commit ded3f168e5204c2a88d23df02fd89c935f149d2c Author: Rishabh Patel rishabh.mahendra.pa...@gmail.com Date: 2015-06-25T19:45:38Z Fixed potential resource leaks Potential resource leak in WordDictionary.java -- Key: LUCENE-6610 URL: https://issues.apache.org/jira/browse/LUCENE-6610 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Priority: Minor Labels: github-pullrequest The input and output object stream might not get closed upon an exception. Fix with try-with-resources construct. -- 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-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601826#comment-14601826 ] ASF subversion and git services commented on SOLR-7560: --- Commit 1687623 from [~joel.bernstein] in branch 'dev/trunk' [ https://svn.apache.org/r1687623 ] SOLR-7560: Removing Presto 0.107 SHA1 Parallel SQL Support Key: SOLR-7560 URL: https://issues.apache.org/jira/browse/SOLR-7560 Project: Solr Issue Type: New Feature Components: clients - java, search Reporter: Joel Bernstein Fix For: 5.3 Attachments: SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch This ticket provides support for executing *Parallel SQL* queries across SolrCloud collections. The SQL engine will be built on top of the Streaming API (SOLR-7082), which provides support for *parallel relational algebra* and *real-time map-reduce*. Basic design: 1) A new SQLHandler will be added to process SQL requests. The SQL statements will be compiled to live Streaming API objects for parallel execution across SolrCloud worker nodes. 2) SolrCloud collections will be abstracted as *Relational Tables*. 3) The Presto SQL parser will be used to parse the SQL statements. 4) A JDBC thin client will be added as a Solrj client. This ticket will focus on putting the framework in place and providing basic SELECT support and GROUP BY aggregate support. Future releases will build on this framework to provide additional SQL features. -- 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-6610) Potential resource leak in WordDictionary.java
Rishabh Patel created LUCENE-6610: - Summary: Potential resource leak in WordDictionary.java Key: LUCENE-6610 URL: https://issues.apache.org/jira/browse/LUCENE-6610 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Priority: Minor The input and output object stream might not get closed upon an exception. Fix with try-with-resources construct. -- 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 # 52975 - Failure!
BUILD FAILURE Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/52975/ Project:lucene_linux_java8_64_test_only Randomization: JDKEA9,local,heap[934m],-server +UseG1GC +UseCompressedOops Date of build:Thu, 25 Jun 2015 22:47:37 +0200 Build duration:4 min 14 sec CHANGES No Changes BUILD ARTIFACTS checkout/lucene/build/analysis/common/test/temp/junit4-J0-20150625_225052_543.events checkout/lucene/build/analysis/common/test/temp/junit4-J1-20150625_225052_543.events checkout/lucene/build/analysis/common/test/temp/junit4-J2-20150625_225052_543.events checkout/lucene/build/analysis/common/test/temp/junit4-J3-20150625_225052_543.events checkout/lucene/build/analysis/common/test/temp/junit4-J4-20150625_225052_543.events checkout/lucene/build/analysis/common/test/temp/junit4-J5-20150625_225052_547.events checkout/lucene/build/analysis/common/test/temp/junit4-J6-20150625_225052_547.events checkout/lucene/build/analysis/common/test/temp/junit4-J7-20150625_225052_547.events FAILED JUNIT TESTS Name: org.apache.lucene.analysis.miscellaneous Failed: 1 test(s), Passed: 155 test(s), Skipped: 0 test(s), Total: 156 test(s) Failed: org.apache.lucene.analysis.miscellaneous.TestWordDelimiterFilter.testRandomHugeStrings CONSOLE OUTPUT [...truncated 3332 lines...] [junit4] JVM J0: 0.90 ..54.59 =53.69s [junit4] JVM J1: 0.90 ..54.66 =53.76s [junit4] JVM J2: 0.97 ..53.58 =52.61s [junit4] JVM J3: 0.90 ..54.31 =53.41s [junit4] JVM J4: 1.18 ..56.18 =55.00s [junit4] JVM J5: 0.95 ..53.44 =52.49s [junit4] JVM J6: 1.20 ..53.44 =52.24s [junit4] JVM J7: 0.95 ..54.42 =53.47s [junit4] Execution time total: 56 seconds [junit4] Tests summary: 273 suites, 1432 tests, 1 error, 1 ignored 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/analysis/build.xml:106: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/analysis/build.xml:38: 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: 273 suites, 1432 tests, 1 error, 1 ignored Total time: 3 minutes 59 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDKEA9,local,heap[934m],-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] [Created] (LUCENE-6613) TestStressIndexing2.testRandom() failure
Steve Rowe created LUCENE-6613:
--
Summary: TestStressIndexing2.testRandom() failure
Key: LUCENE-6613
URL: https://issues.apache.org/jira/browse/LUCENE-6613
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Steve Rowe
TestStressIndexing2.testRandom() failed on 26/100 iterations on Linux branch_5x
r1687672 with Oracle Java8 using the seed from the repro line below, but only
if I exclude {{-Dtests.method=testRandom}} - I got 100 straight successes when
specifying the method. On OS X this seed failed only 6/100 iterations (again
not specifying {{tests.method}}):
{noformat}
[junit4] Suite: org.apache.lucene.index.TestStressIndexing2
[junit4] OK 0.88s | TestStressIndexing2.testMultiConfig
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtests.method=testRandom -Dtests.seed=3B1EEC65B79DA8C2 -Dtests.slow=true
-Dtests.locale=hr_HR -Dtests.timezone=America/Manaus -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.17s | TestStressIndexing2.testRandom
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 4
[junit4]at
__randomizedtesting.SeedInfo.seed([3B1EEC65B79DA8C2:4952C96A06FD1EB1]:0)
[junit4]at
org.apache.lucene.codecs.memory.DirectPostingsFormat$LowFreqDocsEnum.nextDoc(DirectPostingsFormat.java:1715)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:510)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:270)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.testRandom(TestStressIndexing2.java:77)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] OK 0.09s | TestStressIndexing2.testRandomIWReader
[junit4] 2 NOTE: leaving temporary files on disk at:
/home/sarowe/svn/lucene/dev/branches/branch_5x/lucene/build/core/test/J0/temp/lucene.index.TestStressIndexing2_3B1EEC65B79DA8C2-001
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{f72=FSTOrd50, f50=FSTOrd50, f96=PostingsFormat(name=Direct),
f52=PostingsFormat(name=Direct), f30=PostingsFormat(name=Direct), f54=FSTOrd50,
f75=PostingsFormat(name=LuceneVarGapFixedInterval),
f97=PostingsFormat(name=LuceneVarGapFixedInterval),
f12=PostingsFormat(name=Direct), f58=FSTOrd50, f59=FST50, f4=FST50,
f9=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct), f80=FST50,
f41=PostingsFormat(name=Direct), f85=PostingsFormat(name=Direct), f21=FSTOrd50,
f64=PostingsFormat(name=LuceneVarGapFixedInterval),
f42=PostingsFormat(name=LuceneVarGapFixedInterval),
f20=PostingsFormat(name=LuceneVarGapFixedInterval), f44=FST50,
f49=PostingsFormat(name=Direct), f29=FSTOrd50, f92=PostingsFormat(name=Direct),
f70=PostingsFormat(name=Direct), f91=FST50}, docValues:{},
sim=DefaultSimilarity, locale=hr_HR, timezone=America/Manaus
[junit4] 2 NOTE: Linux 4.1.0-custom1-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=450238456,total=514850816
[junit4] 2 NOTE: All tests run in this JVM: [TestStressIndexing2]
[junit4] Completed [1/1] in 1.43s, 3 tests, 1 error FAILURES!
{noformat}
Original failure here:
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/310/]
--
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-6613) TestStressIndexing2.testRandom() failure
[
https://issues.apache.org/jira/browse/LUCENE-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602406#comment-14602406
]
Steve Rowe commented on LUCENE-6613:
Policeman Jenkins found another failing seed, for
{{TestStressIndexing2.testMultiConfig()}} at
[http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13211/]:
{noformat}
[junit4] Suite: org.apache.lucene.index.TestStressIndexing2
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2
-Dtests.method=testMultiConfig -Dtests.seed=2692E639098F3933
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko_KR
-Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.08s J0 | TestStressIndexing2.testMultiConfig
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 4
[junit4]at
__randomizedtesting.SeedInfo.seed([2692E639098F3933:EB0090E1A4D9267D]:0)
[junit4]at
org.apache.lucene.codecs.memory.DirectPostingsFormat$LowFreqDocsEnum.nextDoc(DirectPostingsFormat.java:1683)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:546)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:270)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.testMultiConfig(TestStressIndexing2.java:113)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{f72=PostingsFormat(name=Direct), f96=PostingsFormat(name=Memory doPackFST=
false), f30=PostingsFormat(name=Memory doPackFST= false),
f74=PostingsFormat(name=Memory doPackFST= false),
f51=PostingsFormat(name=LuceneVarGapFixedInterval),
f76=PostingsFormat(name=Direct), f32=PostingsFormat(name=Direct),
f31=PostingsFormat(name=Asserting),
f33=PostingsFormat(name=LuceneVarGapFixedInterval),
f11=PostingsFormat(name=LuceneVarGapFixedInterval),
f36=PostingsFormat(name=Direct), f13=PostingsFormat(name=Asserting),
f57=PostingsFormat(name=Asserting), f79=PostingsFormat(name=Asserting),
f16=PostingsFormat(name=Memory doPackFST= false),
f38=PostingsFormat(name=Memory doPackFST= false),
f59=PostingsFormat(name=LuceneVarGapFixedInterval),
f15=PostingsFormat(name=LuceneVarGapFixedInterval),
f1=PostingsFormat(name=Memory doPackFST= false),
f3=PostingsFormat(name=Direct), f5=PostingsFormat(name=Memory doPackFST=
false), f7=PostingsFormat(name=Direct), id=PostingsFormat(name=Memory
doPackFST= false), f80=PostingsFormat(name=LuceneVarGapFixedInterval),
f82=PostingsFormat(name=Asserting),
f62=PostingsFormat(name=LuceneVarGapFixedInterval),
f43=PostingsFormat(name=Direct), f86=PostingsFormat(name=Asserting),
f45=PostingsFormat(name=Memory doPackFST= false),
f89=PostingsFormat(name=Memory doPackFST= false),
f22=PostingsFormat(name=LuceneVarGapFixedInterval),
f47=PostingsFormat(name=Direct), f69=PostingsFormat(name=Direct),
f68=PostingsFormat(name=Asserting),
f26=PostingsFormat(name=LuceneVarGapFixedInterval)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=false,coord=no): {f72=DFR GB2, f96=DFR
I(F)B2, f30=DFR I(ne)L3(800.0), f74=LM Jelinek-Mercer(0.10), f51=DFR
I(ne)1, f76=DFR I(ne)B1, f32=DFR I(n)Z(0.3), f31=BM25(k1=1.2,b=0.75), f33=DFR
I(F)2, f11=DFR I(ne)LZ(0.3), f36=IB LL-D1, f13=BM25(k1=1.2,b=0.75), f16=DFR
I(F)L1, f38=DefaultSimilarity, f59=DFR I(n)L2, f15=DFR I(F)2, f3=DFR
I(F)Z(0.3), f7=DFR I(ne)B2, f80=DFR I(ne)1, f82=DFR I(ne)2, f62=IB SPL-LZ(0.3),
f86=DFR I(ne)Z(0.3), f45=DFR I(ne)L1, f89=DFR G1, f22=DFR I(ne)3(800.0), f47=IB
SPL-D1, f69=DFR I(F)L3(800.0), f68=DFR I(ne)Z(0.3), f26=DFR I(F)1},
locale=ko_KR, timezone=Asia/Srednekolymsk
[junit4] 2 NOTE: Linux 3.13.0-54-generic i386/Oracle Corporation 1.9.0-ea
(32-bit)/cpus=12,threads=1,free=93621784,total=253755392
[junit4] 2 NOTE: All tests run in this JVM: [TestConjunctions,
TestSumDocFreq, TestIndexWriterDelete, TestIndexWriterMergePolicy,
TestPayloadNearQuery, TestPersistentSnapshotDeletionPolicy, TestNot,
TestPriorityQueue, TestStressIndexing2]
[junit4] Completed [14/393] on J0 in 0.23s, 3 tests, 1 error FAILURES!
{noformat}
TestStressIndexing2.testRandom() failure
Key: LUCENE-6613
URL: https://issues.apache.org/jira/browse/LUCENE-6613
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Steve Rowe
TestStressIndexing2.testRandom() failed on 26/100 iterations on Linux
branch_5x r1687672 with Oracle Java8 using the seed from the repro line
below, but only if I exclude {{-Dtests.method=testRandom}} - I got 100
straight successes when specifying the method. On OS X this seed failed only
6/100 iterations (again not specifying {{tests.method}}):
{noformat}
[jira] [Updated] (LUCENE-6613) TestStressIndexing2 failures
[
https://issues.apache.org/jira/browse/LUCENE-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-6613:
---
Summary: TestStressIndexing2 failures (was:
TestStressIndexing2.testRandom() failure)
TestStressIndexing2 failures
Key: LUCENE-6613
URL: https://issues.apache.org/jira/browse/LUCENE-6613
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Steve Rowe
TestStressIndexing2.testRandom() failed on 26/100 iterations on Linux
branch_5x r1687672 with Oracle Java8 using the seed from the repro line
below, but only if I exclude {{-Dtests.method=testRandom}} - I got 100
straight successes when specifying the method. On OS X this seed failed only
6/100 iterations (again not specifying {{tests.method}}):
{noformat}
[junit4] Suite: org.apache.lucene.index.TestStressIndexing2
[junit4] OK 0.88s | TestStressIndexing2.testMultiConfig
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestStressIndexing2 -Dtests.method=testRandom
-Dtests.seed=3B1EEC65B79DA8C2 -Dtests.slow=true -Dtests.locale=hr_HR
-Dtests.timezone=America/Manaus -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.17s | TestStressIndexing2.testRandom
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 4
[junit4]at
__randomizedtesting.SeedInfo.seed([3B1EEC65B79DA8C2:4952C96A06FD1EB1]:0)
[junit4]at
org.apache.lucene.codecs.memory.DirectPostingsFormat$LowFreqDocsEnum.nextDoc(DirectPostingsFormat.java:1715)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:510)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:270)
[junit4]at
org.apache.lucene.index.TestStressIndexing2.testRandom(TestStressIndexing2.java:77)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] OK 0.09s | TestStressIndexing2.testRandomIWReader
[junit4] 2 NOTE: leaving temporary files on disk at:
/home/sarowe/svn/lucene/dev/branches/branch_5x/lucene/build/core/test/J0/temp/lucene.index.TestStressIndexing2_3B1EEC65B79DA8C2-001
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{f72=FSTOrd50, f50=FSTOrd50, f96=PostingsFormat(name=Direct),
f52=PostingsFormat(name=Direct), f30=PostingsFormat(name=Direct),
f54=FSTOrd50, f75=PostingsFormat(name=LuceneVarGapFixedInterval),
f97=PostingsFormat(name=LuceneVarGapFixedInterval),
f12=PostingsFormat(name=Direct), f58=FSTOrd50, f59=FST50, f4=FST50,
f9=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct), f80=FST50,
f41=PostingsFormat(name=Direct), f85=PostingsFormat(name=Direct),
f21=FSTOrd50, f64=PostingsFormat(name=LuceneVarGapFixedInterval),
f42=PostingsFormat(name=LuceneVarGapFixedInterval),
f20=PostingsFormat(name=LuceneVarGapFixedInterval), f44=FST50,
f49=PostingsFormat(name=Direct), f29=FSTOrd50,
f92=PostingsFormat(name=Direct), f70=PostingsFormat(name=Direct), f91=FST50},
docValues:{}, sim=DefaultSimilarity, locale=hr_HR, timezone=America/Manaus
[junit4] 2 NOTE: Linux 4.1.0-custom1-amd64 amd64/Oracle Corporation
1.8.0_45 (64-bit)/cpus=16,threads=1,free=450238456,total=514850816
[junit4] 2 NOTE: All tests run in this JVM: [TestStressIndexing2]
[junit4] Completed [1/1] in 1.43s, 3 tests, 1 error FAILURES!
{noformat}
Original failure here:
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/310/]
--
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 (32bit/jdk1.9.0-ea-b60) - Build # 13211 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13211/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.index.TestStressIndexing2.testMultiConfig Error Message: 4 Stack Trace: java.lang.ArrayIndexOutOfBoundsException: 4 at __randomizedtesting.SeedInfo.seed([2692E639098F3933:EB0090E1A4D9267D]:0) at org.apache.lucene.codecs.memory.DirectPostingsFormat$LowFreqDocsEnum.nextDoc(DirectPostingsFormat.java:1683) at org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:546) at org.apache.lucene.index.TestStressIndexing2.verifyEquals(TestStressIndexing2.java:270) at org.apache.lucene.index.TestStressIndexing2.testMultiConfig(TestStressIndexing2.java:113) 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.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 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 550 lines...] [junit4] Suite: org.apache.lucene.index.TestStressIndexing2 [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestStressIndexing2 -Dtests.method=testMultiConfig -Dtests.seed=2692E639098F3933 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko_KR -Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] ERROR 0.08s J0 | TestStressIndexing2.testMultiConfig [junit4] Throwable #1:
[jira] [Resolved] (LUCENE-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException
[
https://issues.apache.org/jira/browse/LUCENE-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-6597.
--
Resolution: Fixed
Assignee: David Smiley
Fix Version/s: 5.3
Thanks Karl.
0-diameter circle was definitely not needed; was just seeing if it'd be
particularly easy.
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
Assignee: David Smiley
Fix For: 5.3
Attachments: LUCENE-6597.patch
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] [Reopened] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reopened SOLR-7719: --- thanks Alessandro for your patch, I'm reopening it as it should be mark as resolved once the patch (or anyway a fix for the issue) gets committed. Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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] (LUCENE-6553) Simplify how we handle deleted docs in read APIs
[ https://issues.apache.org/jira/browse/LUCENE-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6553: - Fix Version/s: (was: Trunk) 5.3 Simplify how we handle deleted docs in read APIs Key: LUCENE-6553 URL: https://issues.apache.org/jira/browse/LUCENE-6553 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6553.patch Today, all scorers and postings formats need to be able to handle deleted documents. I suspect that the reason is that we want to be able to make sure to not perform costly operations on documents that are deleted. For instance if you run a phrase query, reading positions on a document which is deleted is useless. I suspect this is also a source of inefficiencies since in some cases we apply deleted documents several times: for instance conjunctions apply deleted docs to every sub scorer. However, with the new two-phase iteration API, we have a way to make sure that we never run expensive operations on deleted documents: we could first iterate over the approximation, then check that the document is not deleted, and finally confirm the match. Since approximations are cheap, applying deleted docs after them would not be an issue. I would like to explore removing the Bits acceptDocs parameter from TermsEnum.postings, Weight.scorer, SpanWeight.getSpans and Weight.BulkScorer, and add it to BulkScorer.score. This way, bulk scorers would be the only API which would need to know how to apply deleted docs, which I think would be more manageable since we only have 3 or 4 impls. And DefaultBulkScorer would be implemented the way described above: first advance the approximation, then check deleted docs, then confirm the match, then collect. Of course that's only in the case the scorer supports approximations, if it does not, it means it is cheap so we can directly iterate the scorer and check deleted docs on top. -- 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] [Resolved] (LUCENE-6601) Change FilteredQuery.FilterStrategy to use the two-phase iteration API
[ https://issues.apache.org/jira/browse/LUCENE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6601. -- Resolution: Fixed Change FilteredQuery.FilterStrategy to use the two-phase iteration API -- Key: LUCENE-6601 URL: https://issues.apache.org/jira/browse/LUCENE-6601 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6601.patch We could change FilterStrategy so that instead of being a factory of scorers, it would just rewrite filters in such a way that they can decide which of the iterator or random-access API should be used. -- 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: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13200 - Still Failing!
Hmm i dont know whats going on here. I don't like that its an older -ea, but we don't see this with our jenkins server running b64 (newer). Not sure whether to dig in or not, might be a complete waste of time. On Thu, Jun 25, 2015 at 5:16 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13200/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormat.testRandomStoredFields Error Message: bits.deleted=171 info.delcount=0 newdelcount=43 (resource=_1_1.liv) Stack Trace: org.apache.lucene.index.CorruptIndexException: bits.deleted=171 info.delcount=0 newdelcount=43 (resource=_1_1.liv) at __randomizedtesting.SeedInfo.seed([1298184729FBF3FC:5CE7830DB345FB4B]:0) at org.apache.lucene.codecs.lucene50.Lucene50LiveDocsFormat.writeLiveDocs(Lucene50LiveDocsFormat.java:114) at org.apache.lucene.index.DocumentsWriterPerThread.sealFlushedSegment(DocumentsWriterPerThread.java:526) at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:458) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:513) at org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:383) at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:476) at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1359) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1138) at org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:151) at org.apache.lucene.index.BaseStoredFieldsFormatTestCase.testRandomStoredFields(BaseStoredFieldsFormatTestCase.java:127) 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.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 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
[jira] [Commented] (LUCENE-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException
[
https://issues.apache.org/jira/browse/LUCENE-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601126#comment-14601126
]
ASF subversion and git services commented on LUCENE-6597:
-
Commit 1687499 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1687499 ]
LUCENE-6597: Geo3D's GeoCircle now supports a world-globe diameter.
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
Attachments: LUCENE-6597.patch
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] [Commented] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601193#comment-14601193 ] Alessandro Benedetti commented on SOLR-7719: Many thanks :D I did not know exactly the Solr Jira workflow, so when a patch is provided I was thinking an issue status change should have happened. Good to know ! Is anything the patcher must provide more, to obtain a feedback ? Or simply providing the patch is enough ? Cheers Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-6578: Attachment: LUCENE-6578.revised.patch Revised patch cutting back on the size of the diff. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601110#comment-14601110 ] Michael McCandless commented on LUCENE-6578: But I don't think that should block committing this! Such improvements can be made later ... Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6590: - Attachment: LUCENE-6590.patch I started playing with this idea and here is a first step (only lucene/core and would deserve better docs but tests are passing) if someone would like to have a look. Clone, setBoost and getBoost are removed from the Query API in favour of a new BoostQuery, and query boosts are propagated through Query.createWeight. Next step is to figure out if we can remove this queryBoost parameter from createWeight (to get back to today's trunk signature) and handle everything through Weight.normalize like Robert suggested. Explore different ways to apply boosts -- Key: LUCENE-6590 URL: https://issues.apache.org/jira/browse/LUCENE-6590 Project: Lucene - Core Issue Type: Wish Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6590.patch Follow-up from LUCENE-6570: the fact that all queries are mutable in order to allow for applying a boost raises issues since it makes queries bad cache keys since their hashcode can change anytime. We could just document that queries should never be modified after they have gone through IndexSearcher but it would be even better if the API made queries impossible to mutate at all. I think there are two main options: - either replace void setBoost(boost) with something like Query withBoost(boost) which would return a clone that has a different boost - or move boost handling outside of Query, for instance we could have a (immutable) query impl that would be dedicated to applying boosts, that queries that need to change boosts at rewrite time (such as BooleanQuery) would use as a wrapper. The latter idea is from Robert and I like it a lot given how often I either introduced or found a bug which was due to the boost parameter being ignored. Maybe there are other options, but I think this is worth exploring. -- 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] [Resolved] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti resolved SOLR-7719. Resolution: Implemented Patch provided Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Priority: Minor Labels: queryResponse, suggester, suggestions Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-7692) Implement BasicAuth based impl for the new Authentication/Authorization APIs
[
https://issues.apache.org/jira/browse/SOLR-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7692:
-
Description:
This involves various components
h2. Authentication
A basic auth based authentication filter. This should retrieve the user
credentials from ZK. The user name and sha1 hash of password should be stored
in ZK
sample authentication json
{code:javascript}
{
authentication:{
class: solr.BasicAuth,
users :{
john :{09fljnklnoiuy98,
david:f678njfgfjnklnoiuy9865ty,
pete: 87ykjnklndfhjh898uyiy98,
}
}
}
{code}
h2. authorization plugin
This would store the roles of various users and their privileges in ZK
sample authorization.json
{code:javascript}
{
authorization: {
class: solr.ZKAuthorization,
roles :{
admin : [john]
guest : [john, david,pete]
}
permissions: {
collectionadmin: {
roles: [admin]
},
coreadmin:{
roles:[admin]
},
config-api: {
//all collections
roles: [admin]
},
schema-api: {
roles: [admin]
},
update: {
//all collections
roles: null
},
query:{
roles:null
},
mycoll_update: {
collection: mycoll,
path:[/update/*],
roles: [somebody]//create a dir called /keys/somebody and put in
usr.pwd files
}
}
}
}
{code}
We will also need to provide APIs to create users and assign them roles
was:
This involves various components
h2. Authentication
A basic auth based authentication filter. This should retrieve the user
credentials from ZK. The user name and sha1 hash of password should be stored
in ZK
sample authentication json
{code:javascript}
{
authentication:{
class: solr.BasicAuth,
users :{
john :{
pwd:09fljnklnoiuy98,
role:[admin, guest]
},
david:{
pwd:f678njfgfjnklnoiuy9865ty,
role:[guest]
},
pete: {
pwd:87ykjnklndfhjh898uyiy98,
role:[guest]
}
}
}
}
{code}
h2. authorization plugin
This would store the roles of various users and their privileges in ZK
sample authorization.json
{code:javascript}
{
authorization: {
class: solr.ZKAuthorization,
permissions: {
collectionadmin: {
roles: [admin]
},
coreadmin:{
roles:[admin]
},
config-api: {
//all collections
roles: [admin]
},
schema-api: {
roles: [admin]
},
update: {
//all collections
roles: null
},
query:{
roles:null
},
mycoll_update: {
collection: mycoll,
path:[/update/*],
roles: [somebody]//create a dir called /keys/somebody and put in
usr.pwd files
}
}
}
}
{code}
We will also need to provide APIs to create users and assign them roles
Implement BasicAuth based impl for the new Authentication/Authorization APIs
Key: SOLR-7692
URL: https://issues.apache.org/jira/browse/SOLR-7692
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
This involves various components
h2. Authentication
A basic auth based authentication filter. This should retrieve the user
credentials from ZK. The user name and sha1 hash of password should be
stored in ZK
sample authentication json
{code:javascript}
{
authentication:{
class: solr.BasicAuth,
users :{
john :{09fljnklnoiuy98,
david:f678njfgfjnklnoiuy9865ty,
pete: 87ykjnklndfhjh898uyiy98,
}
}
}
{code}
h2. authorization plugin
This would store the roles of various users and their privileges in ZK
sample authorization.json
{code:javascript}
{
authorization: {
class: solr.ZKAuthorization,
roles :{
admin : [john]
guest : [john, david,pete]
}
permissions: {
collectionadmin: {
roles: [admin]
},
coreadmin:{
roles:[admin]
},
config-api: {
//all collections
roles: [admin]
},
schema-api: {
roles: [admin]
},
update: {
//all collections
roles: null
},
query:{
roles:null
},
mycoll_update: {
collection: mycoll,
path:[/update/*],
roles: [somebody]//create a dir called /keys/somebody and put in
usr.pwd files
}
}
}
}
{code}
We will also need to provide APIs to create users and assign them roles
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
[jira] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601207#comment-14601207 ] Karl Wright commented on LUCENE-6578: - Also, FWIW, it's rather timeconsuming to make multiple iterative little tweaky changes to every single shape class. It's much much better to arrive at a solution that is acceptable before I go off and code anything else. So please, let us do that rather than waste my time any further. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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 # 2452 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2452/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 5 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([AE9AC7D7D21F43F5]: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.GeneratedMethodAccessor32.invoke(Unknown Source) 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.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([AE9AC7D7D21F43F5]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232) at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) 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
[jira] [Commented] (SOLR-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[ https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601011#comment-14601011 ] Upayavira commented on SOLR-7639: - It appears that the MLTQParser does not support stream.body, which for me is the killer feature of the MLTRequestHandler. The documents I want to use as a query simply aren't in the index. I did attempt to write my own query parser a while back, but hit a recently added limitation that a SearchHandler cannot have access to a stream. Bring MLTQParser at par with the MLT Handler w.r.t supported options Key: SOLR-7639 URL: https://issues.apache.org/jira/browse/SOLR-7639 Project: Solr Issue Type: Improvement Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: 5.3 Attachments: SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639-use-defaults.patch, SOLR-7639.patch, SOLR-7639.patch As of now, there are options that the MLT Handler supports which the QParser doesn't. It would be good to have the QParser tap into everything that's supported. -- 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-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=14601108#comment-14601108 ] ASF subversion and git services commented on SOLR-7499: --- Commit 1687497 from [~varunthacker] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1687497 ] SOLR-7499: Correct formatting in CHANGES entry 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601115#comment-14601115 ] Karl Wright commented on LUCENE-6578: - I stripped the comments out and introduced a full abstract base class hierarchy so we could do at least minimal code sharing. There are downsides but they aren't severe. Let's see what David says. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-6600) Lucene issue concurrency error
[ https://issues.apache.org/jira/browse/LUCENE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601124#comment-14601124 ] Carl Antaki commented on LUCENE-6600: - Here`s the full stack trace: [23/06/15 13:18:15:984 EDT] 0076 SolrCore E org.apache.solr.common.SolrException log java.lang.ArrayIndexOutOfBoundsException: 81 at org.apache.lucene.codecs.lucene45.Lucene45DocValuesProducer$2.get(Lucene45DocValuesProducer.java:323) at org.apache.lucene.util.LongValues.get(LongValues.java:35) at org.apache.lucene.search.suggest.analyzing.BlendedInfixSuggester.createResults(BlendedInfixSuggester.java:152) at org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.lookup(AnalyzingInfixSuggester.java:437) at org.apache.lucene.search.suggest.analyzing.BlendedInfixSuggester.lookup(BlendedInfixSuggester.java:122) at org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.lookup(AnalyzingInfixSuggester.java:338) at org.apache.lucene.search.suggest.analyzing.BlendedInfixSuggester.lookup(BlendedInfixSuggester.java:116) at org.apache.solr.spelling.suggest.SolrSuggester.getSuggestions(SolrSuggester.java:181) at org.apache.solr.handler.component.SuggestComponent.process(SuggestComponent.java:232) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:217) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:241) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:768) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:205) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:997) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.invokeFilters(DefaultExtensionProcessor.java:1062) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:982) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3944) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:931) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1592) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:557) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:607) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:984) at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1069) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1646) Lucene issue concurrency error -- Key: LUCENE-6600 URL: https://issues.apache.org/jira/browse/LUCENE-6600 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7.2 Reporter: Carl Antaki -- 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-6601) Change FilteredQuery.FilterStrategy to use the two-phase iteration API
[ https://issues.apache.org/jira/browse/LUCENE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601150#comment-14601150 ] ASF subversion and git services commented on LUCENE-6601: - Commit 1687515 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1687515 ] LUCENE-6601: Backport CHANGES entries to trunk. Change FilteredQuery.FilterStrategy to use the two-phase iteration API -- Key: LUCENE-6601 URL: https://issues.apache.org/jira/browse/LUCENE-6601 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6601.patch We could change FilterStrategy so that instead of being a factory of scorers, it would just rewrite filters in such a way that they can decide which of the iterator or random-access API should be used. -- 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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[
https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601046#comment-14601046
]
Upayavira commented on SOLR-7639:
-
Looking at the history here:
http://svn.apache.org/viewvc/lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java?r1=1666876r2=1668170
we can see Yonik removed the problematic code:
public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp)
throws Exception
{
-// int sleep = req.getParams().getInt(sleep,0);
-// if (sleep 0) {log.error(SLEEPING for + sleep);
Thread.sleep(sleep);}
-if (req.getContentStreams() != null
req.getContentStreams().iterator().hasNext()) {
- throw new SolrException(ErrorCode.BAD_REQUEST, Search requests cannot
accept content streams);
-}
This means that the MLTQParser should be able to access the stream in the same
way as the MoreLikeThisHandler does.
Bring MLTQParser at par with the MLT Handler w.r.t supported options
Key: SOLR-7639
URL: https://issues.apache.org/jira/browse/SOLR-7639
Project: Solr
Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Fix For: 5.3
Attachments: SOLR-7639-add-boost-and-exclude-current.patch,
SOLR-7639-use-defaults.patch, SOLR-7639.patch, SOLR-7639.patch
As of now, there are options that the MLT Handler supports which the QParser
doesn't. It would be good to have the QParser tap into everything that's
supported.
--
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.9.0-ea-b60) - Build # 13202 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13202/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC 7 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.search.TestStressRecovery Error Message: 6 threads leaked from SUITE scope at org.apache.solr.search.TestStressRecovery: 1) Thread[id=7531, name=WRITER3, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 2) Thread[id=7530, name=WRITER2, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 3) Thread[id=7533, name=WRITER5, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 4) Thread[id=7528, name=WRITER0, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 5) Thread[id=7529, name=WRITER1, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 6) Thread[id=7532, name=WRITER4, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 6 threads leaked from SUITE scope at
[jira] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[
https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601154#comment-14601154
]
David Smiley commented on LUCENE-6578:
--
I'm not in a hurry to commit anything that has this amount of code redundancy
-- sorry. Now is the time to address it; not in an inevitable future issue.
Apparently Mike feels differently. It's great seeing reduced redundant
javadocs in the latest patch -- thanks. By the way, new patches should
generally be named the same in JIRA.
Karl, a specific idea that would reduce the code here a ton is a simple
interface like:
{code:java}
interface DistCalculator {
double calcDistance(x, y, z);
}
{code}
Then each shape needs... perhaps just a single method taking this? There would
be no extra object allocation per distance run.
Geo3d: arcDistanceToShape() method may be useful
Key: LUCENE-6578
URL: https://issues.apache.org/jira/browse/LUCENE-6578
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: Karl Wright
Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch
I've got an application that seems like it may need the ability to compute a
new kind of arc distance, from a GeoPoint to the nearest edge/point of a
GeoShape. Adding this method to the interface, and corresponding
implementations, would increase the utility of the package for ranking
purposes.
--
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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[ https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600983#comment-14600983 ] Markus Jelsma commented on SOLR-7639: - Hi - i have only seen the patch and assume uniqueValue is the docId that is excluded. In case docId's are URL's, are they escaped elsewhere in the code? Bring MLTQParser at par with the MLT Handler w.r.t supported options Key: SOLR-7639 URL: https://issues.apache.org/jira/browse/SOLR-7639 Project: Solr Issue Type: Improvement Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: 5.3 Attachments: SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639-use-defaults.patch, SOLR-7639.patch, SOLR-7639.patch As of now, there are options that the MLT Handler supports which the QParser doesn't. It would be good to have the QParser tap into everything that's supported. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601112#comment-14601112 ] Karl Wright commented on LUCENE-6578: - Thanks, I will keep that in mind for the future. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-7719: --- Attachment: SOLR-7719.patch Please verify if the patch is of good quality ! Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-6601) Change FilteredQuery.FilterStrategy to use the two-phase iteration API
[ https://issues.apache.org/jira/browse/LUCENE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601140#comment-14601140 ] ASF subversion and git services commented on LUCENE-6601: - Commit 1687514 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1687514 ] LUCENE-6601: Make FilteredQuery.FilterStrategy leverage the two-phase iteration API instead of the acceptDocs parameter of the Scorer API. Change FilteredQuery.FilterStrategy to use the two-phase iteration API -- Key: LUCENE-6601 URL: https://issues.apache.org/jira/browse/LUCENE-6601 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6601.patch We could change FilterStrategy so that instead of being a factory of scorers, it would just rewrite filters in such a way that they can decide which of the iterator or random-access API should be used. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601197#comment-14601197 ] Karl Wright commented on LUCENE-6578: - So, I don't understand how introduction of a single interface can somehow create six distance methods in every object? Without any additional object creation? Can you please be more specific? Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-Tests-5.x-Java7 - Build # 3258 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3258/ 1 tests failed. FAILED: org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([C062F72E9252DCA8:97008D07BB838D22]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737) at org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer(TestCustomDocTransformer.java:67) 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 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) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//str[.='xx#title_0#'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime0/int/lstresult name=response numFound=10 start=0docint name=id0/intarr
[jira] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601109#comment-14601109 ] Michael McCandless commented on LUCENE-6578: [~daddywri] we generally don't repeat the javadocs if it's just the same thing that the interface had in the javadocs for that method ... Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601015#comment-14601015 ] Karl Wright commented on LUCENE-6578: - [~mikemccand]: I'd also like your opinion as to whether I should remove javadoc from methods that implement an interface; this seems questionable to me. Does lucene have a best practice for this kind of thing? Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[ https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601017#comment-14601017 ] Markus Jelsma commented on SOLR-7639: - Hello - why is that? SolrQueryRequest in SearchHandler.handleRequestBody() gives you access to the ContentStream is it not? Bring MLTQParser at par with the MLT Handler w.r.t supported options Key: SOLR-7639 URL: https://issues.apache.org/jira/browse/SOLR-7639 Project: Solr Issue Type: Improvement Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: 5.3 Attachments: SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639-use-defaults.patch, SOLR-7639.patch, SOLR-7639.patch As of now, there are options that the MLT Handler supports which the QParser doesn't. It would be good to have the QParser tap into everything that's supported. -- 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] (SOLR-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[
https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601046#comment-14601046
]
Upayavira edited comment on SOLR-7639 at 6/25/15 11:42 AM:
---
Looking at the history here:
http://svn.apache.org/viewvc/lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java?r1=1666876r2=1668170
we can see Yonik removed the problematic code:
{{
public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp)
throws Exception
{
-// int sleep = req.getParams().getInt(sleep,0);
-// if (sleep 0) {log.error(SLEEPING for + sleep);
Thread.sleep(sleep);}
-if (req.getContentStreams() != null
req.getContentStreams().iterator().hasNext()) {
- throw new SolrException(ErrorCode.BAD_REQUEST, Search requests cannot
accept content streams);
-}
}}
This means that the MLTQParser should be able to access the stream in the same
way as the MoreLikeThisHandler does.
was (Author: upayavira):
Looking at the history here:
http://svn.apache.org/viewvc/lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java?r1=1666876r2=1668170
we can see Yonik removed the problematic code:
public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp)
throws Exception
{
-// int sleep = req.getParams().getInt(sleep,0);
-// if (sleep 0) {log.error(SLEEPING for + sleep);
Thread.sleep(sleep);}
-if (req.getContentStreams() != null
req.getContentStreams().iterator().hasNext()) {
- throw new SolrException(ErrorCode.BAD_REQUEST, Search requests cannot
accept content streams);
-}
This means that the MLTQParser should be able to access the stream in the same
way as the MoreLikeThisHandler does.
Bring MLTQParser at par with the MLT Handler w.r.t supported options
Key: SOLR-7639
URL: https://issues.apache.org/jira/browse/SOLR-7639
Project: Solr
Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Fix For: 5.3
Attachments: SOLR-7639-add-boost-and-exclude-current.patch,
SOLR-7639-use-defaults.patch, SOLR-7639.patch, SOLR-7639.patch
As of now, there are options that the MLT Handler supports which the QParser
doesn't. It would be good to have the QParser tap into everything that's
supported.
--
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-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=14601106#comment-14601106 ] ASF subversion and git services commented on SOLR-7499: --- Commit 1687495 from [~varunthacker] in branch 'dev/trunk' [ https://svn.apache.org/r1687495 ] SOLR-7499: Correct formatting in CHANGES entry 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-6597) Geo3d circle creation that covers whole globe throws an IllegalArgumentException
[
https://issues.apache.org/jira/browse/LUCENE-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601132#comment-14601132
]
ASF subversion and git services commented on LUCENE-6597:
-
Commit 1687502 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1687502 ]
LUCENE-6597: Geo3D's GeoCircle now supports a world-globe diameter.
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
Attachments: LUCENE-6597.patch
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
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_45) - Build # 4963 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4963/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseG1GC 3 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([7FC7E50FD82D:F793DAD576D1B025]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:217) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:115) 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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) 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
[Solr J] Suggester and Clustering response support
hi guys, I have already provided a patch to add the client support for the suggester component in SolrJ : https://issues.apache.org/jira/browse/SOLR-7719 As soon as I have time I will create a similar issue for the clustering component. Because it was my first contribution, I am not sure i followed the proper process. Any feedback would be much appreciated. Cheers -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England
Re: [Solr J] Suggester and Clustering response support
Hi Alessandro, Your patch on SOLR-7719 is in the correct format and applies cleanly. So the process you have followed is correct. Now it's upto a committer to take interest and comment on the Jira directly :) I'll try going through your patch in detail later today. On Thu, Jun 25, 2015 at 6:53 PM, Alessandro Benedetti abenede...@apache.org wrote: hi guys, I have already provided a patch to add the client support for the suggester component in SolrJ : https://issues.apache.org/jira/browse/SOLR-7719 As soon as I have time I will create a similar issue for the clustering component. Because it was my first contribution, I am not sure i followed the proper process. Any feedback would be much appreciated. Cheers -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England -- Regards, Varun Thacker
[jira] [Commented] (LUCENE-6600) Lucene issue concurrency error
[ https://issues.apache.org/jira/browse/LUCENE-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601033#comment-14601033 ] Carl Antaki commented on LUCENE-6600: - Hello Mikhail. I repeated the exact case manually and it works. Actually it's the first time I get this kind of error. I'm suspecting it's a concurrency issue because I can't find any other explanation for that. The query that failed had 3 other log statements in the logs at the same millisecond. I looked at the code briefly but I couldn't determine that it's a concurrency issue but this can be hard to determine. I noticed this code was changed in version 5.2 of Lucene but we can't upgrade yet to this version because it requires upgrading Java. I'll post a full stack trace. Lucene issue concurrency error -- Key: LUCENE-6600 URL: https://issues.apache.org/jira/browse/LUCENE-6600 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.7.2 Reporter: Carl Antaki -- 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: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13015 - Failure!
Hi Rory, Maybe add: The first time we have seen this was not in Lucene's code, it happened while compiling our code with Javac. Javac crashed, so the build stopped. This time(in the bug report) it happened while executing Lucene tests. Sorry for not yet updating to later Java 9 builds, but currently newer ones did not work at all because of some problems Robert discovered. I will give a newer one a try soon. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] Sent: Thursday, June 25, 2015 4:49 AM To: dev@lucene.apache.org Cc: rory.odonn...@oracle.com; Balchandra Vaidya; Dalibor Topic; Vivek Theeyarath Subject: Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13015 - Failure! https://bugs.openjdk.java.net/browse/JDK-8129831 Rgds,Rory On 25/06/2015 08:36, Rory O'Donnell wrote: Thanks Robert, will let you know the JBS id shortly. Rgds,Rory On 24/06/2015 22:54, Robert Muir wrote: I filed a bug report with our crash data in case it is useful: JI-9021760 On Wed, Jun 24, 2015 at 5:14 PM, Uwe Schindler u...@thetaphi.de wrote: I changed the artifact pattern to: **/*.events,heapdumps/**,**/*_pid*.log I preserved the current file and sent it to Robert... Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Dawid Weiss [mailto:dawid.we...@gmail.com] Sent: Wednesday, June 24, 2015 4:52 PM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13015 - Failure! I think we should, maybe somebody will have a clue. If they ignore it, so be it. As a side note -- it'd be useful to run a jenkins job on a JVM built with assertions (fastdebug). This way we could run some higher level sanity checks -- hopefully hitting an assertions first, before the sigsegv. Unfortunately Oracle doesn't provide these (we could mention it to Rory?) but we can build openjdk manually. Just a thought. Dawid On Wed, Jun 24, 2015 at 10:44 PM, Robert Muir rcm...@gmail.com wrote: We have seen this jvm crash before: http://www.gossamer-threads.com/lists/lucene/java-dev/274389 Maybe the stacktrace is useful even without a repro and we should report it? By the way, i dont know if the compiler replay data file (replay_pid.log) is useful for debugging these issues, but i think jenkins currently throws it away. V [libjvm.so+0x8d36a4] PhaseIterGVN::add_users_to_worklist0(Node*)+0x14 V [libjvm.so+0x8d37a6] PhaseIterGVN::add_users_to_worklist(Node*)+0x26 V [libjvm.so+0x2de4a8] ArrayCopyNode::finish_transform(PhaseGVN*, bool, Node*, Node*)+0xb8 V [libjvm.so+0x2df3ca] ArrayCopyNode::Ideal(PhaseGVN*, bool)+0x86a V [libjvm.so+0x8d584e] PhaseIterGVN::transform_old(Node*)+0x6e V [libjvm.so+0x8d327c] PhaseIterGVN::optimize()+0x1ac V [libjvm.so+0x46c849] Compile::Optimize()+0x9f9 V [libjvm.so+0x46e0c0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1040 V [libjvm.so+0x3c5c29] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V [libjvm.so+0x47609a] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ba V [libjvm.so+0x476c88] CompileBroker::compiler_thread_loop()+0x4a8 V [libjvm.so+0x9ca038] JavaThread::thread_main_inner()+0xd8 V [libjvm.so+0x9ca1d8] JavaThread::run()+0x158 V [libjvm.so+0x880542] java_start(Thread*)+0xf2 C [libpthread.so.0+0x8182] start_thread+0xc2 Current CompileTask: C2: 72542 11091 % 4 org.apache.lucene.util.automaton.MinimizationOperations::minimize @ 422 (1430 bytes) On Wed, Jun 24, 2015 at 4:36 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13015/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops - XX:+UseSerialGC All tests passed Build Log: [...truncated 4524 lines...] [junit4] JVM J1: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-5.x- Linux/lucene/build/backward- codecs/test/temp/junit4-J1-20150624_203244_919.sysout [junit4] JVM J1: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x7f85a11e06a4, pid=12587, tid=140210996520704 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b60) (build 1.9.0-ea-b60) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b60 mixed mode linux-amd64 ) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x8d36a4] PhaseIterGVN::add_users_to_worklist0(Node*)+0x14 [junit4] # [junit4] # Failed to write core dump. Core dumps have been
[jira] [Resolved] (SOLR-7702) Optionally disable null for all zero's in spatial heatmap
[
https://issues.apache.org/jira/browse/SOLR-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-7702.
Resolution: Cannot Reproduce
Optionally disable null for all zero's in spatial heatmap
-
Key: SOLR-7702
URL: https://issues.apache.org/jira/browse/SOLR-7702
Project: Solr
Issue Type: Bug
Affects Versions: 5.2
Reporter: Markus Jelsma
Assignee: David Smiley
Fix For: 5.3
Attachments: SOLR-7702.patch, SOLR-7702.patch
Parsing all those null entries in a NamedList seems impossible via SolrJ.
{code}
lst name=facet_heatmapslst name=coordint
name=gridLevel3/intint name=columns256/intint
name=rows128/intdouble name=minX-180.0/doubledouble
name=maxX180.0/doubledouble name=minY-90.0/doubledouble
name=maxY90.0/doublearr
name=counts_ints2Dnull/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/null/arrint0/intint0/intint0/intint0/intint0/intint0/intint0/intint0/intint0/intint0/intint0/intint0/int
{code}
All namedList methods that can retrieve counts_ints2d return null. This patch
adds a setting to not to return null for all zeros.
--
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-6608) Potential resource leak in BigramDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601797#comment-14601797 ] ASF GitHub Bot commented on LUCENE-6608: GitHub user rmp91 opened a pull request: https://github.com/apache/lucene-solr/pull/161 LUCENE-6608: solved potential resource leakage https://issues.apache.org/jira/browse/LUCENE-6608 You can merge this pull request into a Git repository by running: $ git pull https://github.com/rmp91/lucene-solr LUCENE-6608 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/161.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 #161 commit 2f9abc607d083a3e1dee95b3d715ffce05839415 Author: Rishabh Patel rishabh.mahendra.pa...@gmail.com Date: 2015-06-25T19:32:59Z solved potential resource leakage Potential resource leak in BigramDictionary.java Key: LUCENE-6608 URL: https://issues.apache.org/jira/browse/LUCENE-6608 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Priority: Minor Labels: github-import The input and output object streams are being closed in the try block. These resources will not be closed if an exception occurs in the try block We can use the finally block to explicitly close these resources or use the new try-with-resources construct where they are implicitly closed. -- 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] (LUCENE-6608) Potential resource leak in BigramDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-6608: - Assignee: Uwe Schindler Hi thanks for reporting this. I will take care of this issue! Potential resource leak in BigramDictionary.java Key: LUCENE-6608 URL: https://issues.apache.org/jira/browse/LUCENE-6608 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Assignee: Uwe Schindler Priority: Minor Labels: github-import The input and output object streams are being closed in the try block. These resources will not be closed if an exception occurs in the try block We can use the finally block to explicitly close these resources or use the new try-with-resources construct where they are implicitly closed. -- 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.9.0-ea-b60) - Build # 13206 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13206/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 52047 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:433: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:105: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:208: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/presto-parser-0.107.jar.sha1 Total time: 53 minutes 11 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13206 - Still Failing!
Fixing this ... Joel Bernstein http://joelsolr.blogspot.com/ On Thu, Jun 25, 2015 at 3:51 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13206/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 52047 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:433: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:105: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:208: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/presto-parser-0.107.jar.sha1 Total time: 53 minutes 11 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6608) Potential resource leak in BigramDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601835#comment-14601835 ] ASF subversion and git services commented on LUCENE-6608: - Commit 1687626 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1687626 ] Merged revision(s) 1687624 from lucene/dev/trunk: LUCENE-6608: Fix potential resource leak in BigramDictionary Potential resource leak in BigramDictionary.java Key: LUCENE-6608 URL: https://issues.apache.org/jira/browse/LUCENE-6608 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Assignee: Uwe Schindler Priority: Minor Labels: github-import The input and output object streams are being closed in the try block. These resources will not be closed if an exception occurs in the try block We can use the finally block to explicitly close these resources or use the new try-with-resources construct where they are implicitly closed. -- 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] [Resolved] (LUCENE-6608) Potential resource leak in BigramDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-6608. --- Resolution: Fixed Thanks, I just committed this. In addition, I removed the empty catch block which was also suppressing Exceptions on storing. Potential resource leak in BigramDictionary.java Key: LUCENE-6608 URL: https://issues.apache.org/jira/browse/LUCENE-6608 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Assignee: Uwe Schindler Priority: Minor Labels: github-import The input and output object streams are being closed in the try block. These resources will not be closed if an exception occurs in the try block We can use the finally block to explicitly close these resources or use the new try-with-resources construct where they are implicitly closed. -- 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.7.0_80) - Build # 13023 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13023/ Java: 32bit/jdk1.7.0_80 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([106A5A19FF48451A:47082030D6991490]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737) at org.apache.solr.response.TestCustomDocTransformer.testCustomTransformer(TestCustomDocTransformer.java:67) 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 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) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//str[.='xx#title_0#'] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime15/int/lstresult name=response
[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=14600957#comment-14600957 ] Modassar Ather commented on LUCENE-5205: Thanks [~talli...@mitre.org] Will integrate and start using it. 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] [Updated] (SOLR-7188) Run Data Import Handler processes in a SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-7188: - Attachment: ESS_as_a_copy.patch running EmbeddedSolrServer as a copy of a live server (Untested) Run Data Import Handler processes in a SolrJ client --- Key: SOLR-7188 URL: https://issues.apache.org/jira/browse/SOLR-7188 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Ted Sullivan Priority: Minor Attachments: ESS_as_a_copy.patch, IDEA-AS-CODE.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch Adds a DataImportHandlerClient class that wraps an EmbeddedSolrServer and adds a DIHCloudWriter implementation of DIHWriter that sends documents to a remote SolrCloud cluster. This enables existing DIH processes to run outside of the Solr JVM which should enable better scalability. The current architecture of DIH imposes several restrictions on scalability. First, the DIH runs in the same process space as Solr itself and competes for resources (CPU and memory) with normal Solr processes devoted to indexing and querying. Second, the DIH cannot be multi-threaded which means that parallelizing it requires splitting the processing amongst nodes in a SolrCloud cluster. Since the incoming data is sent through an UpdateRequestProcessor chain (via the SolrWriter implementation of DIHWriter), additional routing is done internally as the documents are forwarded to the current shard leader nodes once the ID hash is computed. This causes additional network traffic within the SolrCloud cluster. Scaling the DIH is limited by the number of nodes in the cluster and any heavy-duty processing due to entity processors or transformation elements shares the processing resources of Solr itself. This is known to be a source of bottlenecks in Solr installations (SolrCloud or Master-Slave) that use DIH. The DataImportHandlerClient uses native DIH functionality - DataImporter, etc. but can be run externally to Solr. This means that as many processes as are needed to achieve necessary performance at scale can be added and the processing that occurs within the DataImportHandler is done outside of the Solr JVM. The same benefits that accrue with multiple SolrJ clients can now be realized with DIH without the necessity of porting code from DIH to a SolrJ client. -- 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] (SOLR-7188) Run Data Import Handler processes in a SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-7188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600963#comment-14600963 ] Noble Paul edited comment on SOLR-7188 at 6/25/15 10:14 AM: running EmbeddedSolrServer as a copy of a live server (Untested) [~varunthacker] This could be a totally new ticket was (Author: noble.paul): running EmbeddedSolrServer as a copy of a live server (Untested) Run Data Import Handler processes in a SolrJ client --- Key: SOLR-7188 URL: https://issues.apache.org/jira/browse/SOLR-7188 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Ted Sullivan Priority: Minor Attachments: ESS_as_a_copy.patch, IDEA-AS-CODE.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch, SOLR-7188.patch Adds a DataImportHandlerClient class that wraps an EmbeddedSolrServer and adds a DIHCloudWriter implementation of DIHWriter that sends documents to a remote SolrCloud cluster. This enables existing DIH processes to run outside of the Solr JVM which should enable better scalability. The current architecture of DIH imposes several restrictions on scalability. First, the DIH runs in the same process space as Solr itself and competes for resources (CPU and memory) with normal Solr processes devoted to indexing and querying. Second, the DIH cannot be multi-threaded which means that parallelizing it requires splitting the processing amongst nodes in a SolrCloud cluster. Since the incoming data is sent through an UpdateRequestProcessor chain (via the SolrWriter implementation of DIHWriter), additional routing is done internally as the documents are forwarded to the current shard leader nodes once the ID hash is computed. This causes additional network traffic within the SolrCloud cluster. Scaling the DIH is limited by the number of nodes in the cluster and any heavy-duty processing due to entity processors or transformation elements shares the processing resources of Solr itself. This is known to be a source of bottlenecks in Solr installations (SolrCloud or Master-Slave) that use DIH. The DataImportHandlerClient uses native DIH functionality - DataImporter, etc. but can be run externally to Solr. This means that as many processes as are needed to achieve necessary performance at scale can be added and the processing that occurs within the DataImportHandler is done outside of the Solr JVM. The same benefits that accrue with multiple SolrJ clients can now be realized with DIH without the necessity of porting code from DIH to a SolrJ client. -- 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: LUCENE-6608: solved potential resource l...
GitHub user rmp91 opened a pull request: https://github.com/apache/lucene-solr/pull/161 LUCENE-6608: solved potential resource leakage https://issues.apache.org/jira/browse/LUCENE-6608 You can merge this pull request into a Git repository by running: $ git pull https://github.com/rmp91/lucene-solr LUCENE-6608 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/161.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 #161 commit 2f9abc607d083a3e1dee95b3d715ffce05839415 Author: Rishabh Patel rishabh.mahendra.pa...@gmail.com Date: 2015-06-25T19:32:59Z solved potential resource leakage --- 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
[GitHub] lucene-solr pull request: LUCENE-6610:Fixed potential resource lea...
GitHub user rmp91 opened a pull request: https://github.com/apache/lucene-solr/pull/162 LUCENE-6610:Fixed potential resource leaks https://issues.apache.org/jira/browse/LUCENE-6610 You can merge this pull request into a Git repository by running: $ git pull https://github.com/rmp91/lucene-solr LUCENE-6610 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/162.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 #162 commit ded3f168e5204c2a88d23df02fd89c935f149d2c Author: Rishabh Patel rishabh.mahendra.pa...@gmail.com Date: 2015-06-25T19:45:38Z Fixed potential resource leaks --- 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] (LUCENE-6608) Potential resource leak in BigramDictionary.java
[ https://issues.apache.org/jira/browse/LUCENE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601829#comment-14601829 ] ASF subversion and git services commented on LUCENE-6608: - Commit 1687624 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1687624 ] LUCENE-6608: Fix potential resource leak in BigramDictionary Potential resource leak in BigramDictionary.java Key: LUCENE-6608 URL: https://issues.apache.org/jira/browse/LUCENE-6608 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: Trunk Reporter: Rishabh Patel Assignee: Uwe Schindler Priority: Minor Labels: github-import The input and output object streams are being closed in the try block. These resources will not be closed if an exception occurs in the try block We can use the finally block to explicitly close these resources or use the new try-with-resources construct where they are implicitly closed. -- 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-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601798#comment-14601798 ] Joel Bernstein commented on SOLR-7560: -- I think we only need the latest version. I'll remove presto-parser-0.107.jar.sha1 shortly. Parallel SQL Support Key: SOLR-7560 URL: https://issues.apache.org/jira/browse/SOLR-7560 Project: Solr Issue Type: New Feature Components: clients - java, search Reporter: Joel Bernstein Fix For: 5.3 Attachments: SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch This ticket provides support for executing *Parallel SQL* queries across SolrCloud collections. The SQL engine will be built on top of the Streaming API (SOLR-7082), which provides support for *parallel relational algebra* and *real-time map-reduce*. Basic design: 1) A new SQLHandler will be added to process SQL requests. The SQL statements will be compiled to live Streaming API objects for parallel execution across SolrCloud worker nodes. 2) SolrCloud collections will be abstracted as *Relational Tables*. 3) The Presto SQL parser will be used to parse the SQL statements. 4) A JDBC thin client will be added as a Solrj client. This ticket will focus on putting the framework in place and providing basic SELECT support and GROUP BY aggregate support. Future releases will build on this framework to provide additional SQL features. -- 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] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6590: - Attachment: LUCENE-6590.patch New iteration that removes queryBoost from createWeight and applies both the query and the parent boost through Weight.normalize. Here is how it works: 1. Weight.normalize is called a query norm of 1 and the query boost 2. Weight.getValueForNormalization (which may take the query boost into account) is called to compute queryNorm 3. Weight.normalize is called again with queryNorm and a boost which is equal to the query boost multiplied by the boost which is propagated by parent queries. The patch still only touches lucene/core. There is some documentation that needs to be updated, etc. but if someone could look at the API and how boosts are applied, that would be great. When we are happy with the approach then I can spend time fixing modules as well. Explore different ways to apply boosts -- Key: LUCENE-6590 URL: https://issues.apache.org/jira/browse/LUCENE-6590 Project: Lucene - Core Issue Type: Wish Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6590.patch, LUCENE-6590.patch Follow-up from LUCENE-6570: the fact that all queries are mutable in order to allow for applying a boost raises issues since it makes queries bad cache keys since their hashcode can change anytime. We could just document that queries should never be modified after they have gone through IndexSearcher but it would be even better if the API made queries impossible to mutate at all. I think there are two main options: - either replace void setBoost(boost) with something like Query withBoost(boost) which would return a clone that has a different boost - or move boost handling outside of Query, for instance we could have a (immutable) query impl that would be dedicated to applying boosts, that queries that need to change boosts at rewrite time (such as BooleanQuery) would use as a wrapper. The latter idea is from Robert and I like it a lot given how often I either introduced or found a bug which was due to the boost parameter being ignored. Maybe there are other options, but I think this is worth exploring. -- 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-7637) Improve error logging in the zkcli CLUSTERPROP command
[ https://issues.apache.org/jira/browse/SOLR-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan reassigned SOLR-7637: Assignee: Gregory Chanan Improve error logging in the zkcli CLUSTERPROP command -- Key: SOLR-7637 URL: https://issues.apache.org/jira/browse/SOLR-7637 Project: Solr Issue Type: Improvement Reporter: Hrishikesh Gadre Assignee: Gregory Chanan Priority: Trivial Attachments: SOLR-7637.patch SOLR-7176 introduced capability to update Solr cluster properties via ZK CLI. The error logging implemented as part of that fix was not proper (i.e. the actual error was getting masked). We should improve the error logging to explicitly state the root cause. -- 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-7637) Improve error logging in the zkcli CLUSTERPROP command
[ https://issues.apache.org/jira/browse/SOLR-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601945#comment-14601945 ] Gregory Chanan commented on SOLR-7637: -- Why is the first cause the important one to print? Seems arbitrary? Why are the errors going to stderr when all the other errors in the script go to stdout? Improve error logging in the zkcli CLUSTERPROP command -- Key: SOLR-7637 URL: https://issues.apache.org/jira/browse/SOLR-7637 Project: Solr Issue Type: Improvement Reporter: Hrishikesh Gadre Assignee: Gregory Chanan Priority: Trivial Attachments: SOLR-7637.patch SOLR-7176 introduced capability to update Solr cluster properties via ZK CLI. The error logging implemented as part of that fix was not proper (i.e. the actual error was getting masked). We should improve the error logging to explicitly state the root cause. -- 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-7637) Improve error logging in the zkcli CLUSTERPROP command
[ https://issues.apache.org/jira/browse/SOLR-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601977#comment-14601977 ] Hrishikesh Gadre commented on SOLR-7637: Why is the first cause the important one to print? Seems arbitrary? From debugging perspective we are mostly insterested in ZOOKEEPER exception - which is represented by the first cause. Why are the errors going to stderr when all the other errors in the script go to stdout? At least in Cloudera Manager environment, using System.err simplifies debugging since all the script executions are logged in stderr.log file. If we use System.out, the error message will go to stdout.log file instead (which can be confusing for the user). May be add it to both? Improve error logging in the zkcli CLUSTERPROP command -- Key: SOLR-7637 URL: https://issues.apache.org/jira/browse/SOLR-7637 Project: Solr Issue Type: Improvement Reporter: Hrishikesh Gadre Assignee: Gregory Chanan Priority: Trivial Attachments: SOLR-7637.patch SOLR-7176 introduced capability to update Solr cluster properties via ZK CLI. The error logging implemented as part of that fix was not proper (i.e. the actual error was getting masked). We should improve the error logging to explicitly state the root cause. -- 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-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601384#comment-14601384 ] Alessandro Benedetti commented on SOLR-7719: You are completely right, I did the javadoc modification thinking it was nicer, just before sending the patch ( and I did not build again thinking to not have broken anything). Indeed I had. Sending the new patch! Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-6601) Change FilteredQuery.FilterStrategy to use the two-phase iteration API
[ https://issues.apache.org/jira/browse/LUCENE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601415#comment-14601415 ] Joel Bernstein commented on LUCENE-6601: The failure is due to the removal of the createWeight method from the Filter class. I'll need to find a different way to implement: at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) Change FilteredQuery.FilterStrategy to use the two-phase iteration API -- Key: LUCENE-6601 URL: https://issues.apache.org/jira/browse/LUCENE-6601 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6601.patch We could change FilterStrategy so that instead of being a factory of scorers, it would just rewrite filters in such a way that they can decide which of the iterator or random-access API should be used. -- 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-Tests-5.x-Java7 - Build # 3259 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3259/ 2 tests failed. REGRESSION: org.apache.solr.search.TestHashQParserPlugin.testHashPartition Error Message: Query does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query does not implement createWeight at __randomizedtesting.SeedInfo.seed([2C733FFCE6B60D35:FDCE1E19DDDCB45E]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:834) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1146) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1628) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1504) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2058) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.search.TestHashQParserPlugin.testHashPartition(TestHashQParserPlugin.java:94) 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 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
Re: [Solr J] Suggester and Clustering response support
Hi Varun, Alessandro, I've already picked up the issue and follow up there. Regards, Tommaso 2015-06-25 15:50 GMT+02:00 Varun Thacker varunthacker1...@gmail.com: Hi Alessandro, Your patch on SOLR-7719 is in the correct format and applies cleanly. So the process you have followed is correct. Now it's upto a committer to take interest and comment on the Jira directly :) I'll try going through your patch in detail later today. On Thu, Jun 25, 2015 at 6:53 PM, Alessandro Benedetti abenede...@apache.org wrote: hi guys, I have already provided a patch to add the client support for the suggester component in SolrJ : https://issues.apache.org/jira/browse/SOLR-7719 As soon as I have time I will create a similar issue for the clustering component. Because it was my first contribution, I am not sure i followed the proper process. Any feedback would be much appreciated. Cheers -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England -- Regards, Varun Thacker
[jira] [Commented] (SOLR-7719) Suggester Component results parsing
[
https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601283#comment-14601283
]
Tommaso Teofili commented on SOLR-7719:
---
after applying your patch and launching 'ant compile' on trunk I get:
{code}
common.compile-core:
[mkdir] Created dir: lucene/trunk/solr/build/solr-solrj/classes/java
[javac] Compiling 221 source files to
lucene/trunk/solr/build/solr-solrj/classes/java
[javac]
lucene/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/response/SuggesterResponse.java:64:
error: bad use of ''
[javac]* Getter for the map dictionary name - List of Suggestion
objects.
[javac] ^
[javac]
lucene/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/response/SuggesterResponse.java:66:
error: bad use of ''
[javac]* @return a Map dictionary name - List of Suggestion
[javac] ^
[javac]
lucene/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/response/SuggesterResponse.java:73:
error: bad use of ''
[javac]* This getter is lazily initialized and returns a simplified map
dictionary - List of suggested terms
[javac]
^
[javac]
lucene/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/response/SuggesterResponse.java:75:
error: bad use of ''
[javac]* @return a Map dictionary name - List of suggested terms
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors
{code}
I adapted the patch myself (substituted the - chars with : in javadocs), the
patch then compiles correctly and tests pass.
Suggester Component results parsing
---
Key: SOLR-7719
URL: https://issues.apache.org/jira/browse/SOLR-7719
Project: Solr
Issue Type: Improvement
Components: SolrJ
Affects Versions: 5.2.1
Reporter: Alessandro Benedetti
Assignee: Tommaso Teofili
Priority: Minor
Labels: queryResponse, suggester, suggestions
Attachments: SOLR-7719.patch
Original Estimate: 24h
Remaining Estimate: 24h
Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not
managing suggestions coming from the Suggest Component .
It would be nice to have the suggestions properly managed and returned with
simply getter methods.
Current Json :
lst name=suggest
lst name=dictionary1
lst name=queryTerm
int name=numFound2/int
arr name=suggestions
lst
str name=termsuggestion1/str..
str name=termsuggestion2/str…
/lst
/arr
/lst
/lst..
This will be parsed accordingly .
Producing an easy to use Java Map.
Dictionary2suggestions
--
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: [Solr J] Suggester and Clustering response support
Hi Tommaso, Perfect. Thanks for letting us know. On Thu, Jun 25, 2015 at 8:03 PM, Tommaso Teofili tommaso.teof...@gmail.com wrote: Hi Varun, Alessandro, I've already picked up the issue and follow up there. Regards, Tommaso 2015-06-25 15:50 GMT+02:00 Varun Thacker varunthacker1...@gmail.com: Hi Alessandro, Your patch on SOLR-7719 is in the correct format and applies cleanly. So the process you have followed is correct. Now it's upto a committer to take interest and comment on the Jira directly :) I'll try going through your patch in detail later today. On Thu, Jun 25, 2015 at 6:53 PM, Alessandro Benedetti abenede...@apache.org wrote: hi guys, I have already provided a patch to add the client support for the suggester component in SolrJ : https://issues.apache.org/jira/browse/SOLR-7719 As soon as I have time I will create a similar issue for the clustering component. Because it was my first contribution, I am not sure i followed the proper process. Any feedback would be much appreciated. Cheers -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England -- Regards, Varun Thacker -- Regards, Varun Thacker
[jira] [Updated] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-7719: --- Attachment: (was: SOLR-7719.patch) Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti updated SOLR-7719: --- Attachment: SOLR-7719.patch JavaDoc fixed Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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: LUCENE-6606: add SortingMergePolicy's so...
GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/160 LUCENE-6606: add SortingMergePolicy's sorter to SegmentInfo.toString for https://issues.apache.org/jira/i#browse/LUCENE-6606 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-SegmentInfo-toString Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/160.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 #160 commit 49c8fdff29c23d1dcc62aab1cb3fabe0b03daa07 Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-06-23T14:08:30Z LUCENE-: add SortingMergePolicy's sorter (if any) to SegmentInfo.toString Also changed TestSortingMergePolicy.setUp to randomly choose regular or reverse sorting order. --- 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
Re: [Solr J] Suggester and Clustering response support
Thank you very much ! So when I open the next issue ( on clustering) I will simply provide the patch in the same way and wait :) Cheers 2015-06-25 14:50 GMT+01:00 Varun Thacker varunthacker1...@gmail.com: Hi Alessandro, Your patch on SOLR-7719 is in the correct format and applies cleanly. So the process you have followed is correct. Now it's upto a committer to take interest and comment on the Jira directly :) I'll try going through your patch in detail later today. On Thu, Jun 25, 2015 at 6:53 PM, Alessandro Benedetti abenede...@apache.org wrote: hi guys, I have already provided a patch to add the client support for the suggester component in SolrJ : https://issues.apache.org/jira/browse/SOLR-7719 As soon as I have time I will create a similar issue for the clustering component. Because it was my first contribution, I am not sure i followed the proper process. Any feedback would be much appreciated. Cheers -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England -- Regards, Varun Thacker -- -- Benedetti Alessandro Visiting card : http://about.me/alessandro_benedetti Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry? William Blake - Songs of Experience -1794 England
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_45) - Build # 4839 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4839/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.TestHashQParserPlugin.testHashPartition Error Message: Query does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query does not implement createWeight at __randomizedtesting.SeedInfo.seed([3CDD0F5BDDF9D8B3:ED602EBEE69361D8]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:834) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1146) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1628) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1504) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2058) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.search.TestHashQParserPlugin.testHashPartition(TestHashQParserPlugin.java:94) 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 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
[jira] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful
[
https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601276#comment-14601276
]
Karl Wright commented on LUCENE-6578:
-
The distance calculator interface would look then like this:
{code}
public interface DistanceStyle {
/** Compute the distance from a point to another point.
* @param point1 Starting point
* @param point2 Final point
* @return the distance
*/
public double computeDistance(final GeoPoint point1, final GeoPoint point2);
/** Compute the distance from a point to another point.
* @param point1 Starting point
* @param x2 Final point x
* @param y2 Final point y
* @param z2 Final point z
* @return the distance
*/
public double computeDistance(final GeoPoint point1, final double x2, final
double y2, final double z2);
/** Compute the distance from a plane to a point.
* @param planetModel The planet model
* @param plane The plane
* @param point The point
* @return the distance
*/
public double computeDistance(final PlanetModel planetModel, final Plane
plane, final GeoPoint point);
/** Compute the distance from a plane to a point.
* @param planetModel The planet model
* @param plane The plane
* @param x The point x
* @param y The point y
* @param z The point z
* @return the distance
*/
public double computeDistance(final PlanetModel planetModel, final Plane
plane, final double x, final double y, final double z);
}
{code}
Geo3d: arcDistanceToShape() method may be useful
Key: LUCENE-6578
URL: https://issues.apache.org/jira/browse/LUCENE-6578
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: Karl Wright
Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch
I've got an application that seems like it may need the ability to compute a
new kind of arc distance, from a GeoPoint to the nearest edge/point of a
GeoShape. Adding this method to the interface, and corresponding
implementations, would increase the utility of the package for ranking
purposes.
--
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: [JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_45) - Build # 4839 - Failure!
Hi Joel, This is because the query is not rewritten first. I can try to fix it. On Thu, Jun 25, 2015 at 5:13 PM, Joel Bernstein joels...@gmail.com wrote: I'll investigate... Joel Bernstein http://joelsolr.blogspot.com/ On Thu, Jun 25, 2015 at 10:27 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4839/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.TestHashQParserPlugin.testHashPartition Error Message: Query does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query does not implement createWeight at __randomizedtesting.SeedInfo.seed([3CDD0F5BDDF9D8B3:ED602EBEE69361D8]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:834) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1146) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1628) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1504) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2058) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.search.TestHashQParserPlugin.testHashPartition(TestHashQParserPlugin.java:94) 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 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
[jira] [Updated] (SOLR-949) Add QueryResponse and SolrQuery support for TermVectorComponent
[ https://issues.apache.org/jira/browse/SOLR-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Łukasz Dróżdż updated SOLR-949: --- Attachment: SOLR-949.patch Aleksander's patch with fixed formatting and adapted to compile and test against latest trunk (rev. 1687524). Add QueryResponse and SolrQuery support for TermVectorComponent --- Key: SOLR-949 URL: https://issues.apache.org/jira/browse/SOLR-949 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Aleksander M. Stensby Priority: Minor Attachments: SOLR-949.patch, SOLR-949.patch In a similar fashion to Facet information, it would be nice to have support for easily setting TermVector related parameters through SolrQuery, and it would be nice to have methods in QueryResponse to easily retrieve TermVector information -- 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 # 2453 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2453/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.facet.TestDrillSideways.testRandom Error Message: expected:42 but was:44 Stack Trace: java.lang.AssertionError: expected:42 but was:44 at __randomizedtesting.SeedInfo.seed([22909B4E327EB3A5:50DCBE41831E05D6]: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.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.facet.TestDrillSideways.verifyEquals(TestDrillSideways.java:1050) at org.apache.lucene.facet.TestDrillSideways.testRandom(TestDrillSideways.java:756) 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.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 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 6661 lines...] [junit4] Suite: org.apache.lucene.facet.TestDrillSideways [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestDrillSideways -Dtests.method=testRandom -Dtests.seed=22909B4E327EB3A5 -Dtests.slow=true -Dtests.locale=fr_FR -Dtests.timezone=America/Maceio -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 1.41s J0 |
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13026 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13026/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.TestHashQParserPlugin.testHashPartition Error Message: Query does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query does not implement createWeight at __randomizedtesting.SeedInfo.seed([ABA75E60C74B5463:7A1A7F85FC21ED08]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:834) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1146) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1628) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1504) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2058) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.search.TestHashQParserPlugin.testHashPartition(TestHashQParserPlugin.java:94) 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 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
[jira] [Commented] (LUCENE-6601) Change FilteredQuery.FilterStrategy to use the two-phase iteration API
[ https://issues.apache.org/jira/browse/LUCENE-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601392#comment-14601392 ] Joel Bernstein commented on LUCENE-6601: I believe this ticket caused this test failure: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13026/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.TestHashQParserPlugin.testHashPartition Error Message: Query does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query does not implement createWeight at __randomizedtesting.SeedInfo.seed([ABA75E60C74B5463:7A1A7F85FC21ED08]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:851) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:151) ant test -Dtestcase=TestHashQParserPlugin -Dtests.method=testHashPartition -Dtests.seed=3CDD0F5BDDF9D8B3 -Dtests.slow=true -Dtests.locale=iw_IL -Dtests.timezone=Pacific/Johnston -Dtests.asserts=true -Dtests.file.encoding=UTF-8 Change FilteredQuery.FilterStrategy to use the two-phase iteration API -- Key: LUCENE-6601 URL: https://issues.apache.org/jira/browse/LUCENE-6601 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6601.patch We could change FilterStrategy so that instead of being a factory of scorers, it would just rewrite filters in such a way that they can decide which of the iterator or random-access API should be used. -- 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] (SOLR-949) Add QueryResponse and SolrQuery support for TermVectorComponent
[ https://issues.apache.org/jira/browse/SOLR-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601400#comment-14601400 ] Łukasz Dróżdż edited comment on SOLR-949 at 6/25/15 3:47 PM: - I've attached Aleksander's patch with fixed formatting and adapted to compile and test against latest trunk (rev. 1687524). was (Author: ldrozdz): Aleksander's patch with fixed formatting and adapted to compile and test against latest trunk (rev. 1687524). Add QueryResponse and SolrQuery support for TermVectorComponent --- Key: SOLR-949 URL: https://issues.apache.org/jira/browse/SOLR-949 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Aleksander M. Stensby Priority: Minor Attachments: SOLR-949.patch, SOLR-949.patch In a similar fashion to Facet information, it would be nice to have support for easily setting TermVector related parameters through SolrQuery, and it would be nice to have methods in QueryResponse to easily retrieve TermVector information -- 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-6553) Simplify how we handle deleted docs in read APIs
[ https://issues.apache.org/jira/browse/LUCENE-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601237#comment-14601237 ] ASF subversion and git services commented on LUCENE-6553: - Commit 1687524 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1687524 ] LUCENE-6553: Simplify how live docs are applied. Simplify how we handle deleted docs in read APIs Key: LUCENE-6553 URL: https://issues.apache.org/jira/browse/LUCENE-6553 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6553.patch Today, all scorers and postings formats need to be able to handle deleted documents. I suspect that the reason is that we want to be able to make sure to not perform costly operations on documents that are deleted. For instance if you run a phrase query, reading positions on a document which is deleted is useless. I suspect this is also a source of inefficiencies since in some cases we apply deleted documents several times: for instance conjunctions apply deleted docs to every sub scorer. However, with the new two-phase iteration API, we have a way to make sure that we never run expensive operations on deleted documents: we could first iterate over the approximation, then check that the document is not deleted, and finally confirm the match. Since approximations are cheap, applying deleted docs after them would not be an issue. I would like to explore removing the Bits acceptDocs parameter from TermsEnum.postings, Weight.scorer, SpanWeight.getSpans and Weight.BulkScorer, and add it to BulkScorer.score. This way, bulk scorers would be the only API which would need to know how to apply deleted docs, which I think would be more manageable since we only have 3 or 4 impls. And DefaultBulkScorer would be implemented the way described above: first advance the approximation, then check deleted docs, then confirm the match, then collect. Of course that's only in the case the scorer supports approximations, if it does not, it means it is cheap so we can directly iterate the scorer and check deleted docs on top. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601243#comment-14601243 ] Karl Wright commented on LUCENE-6578: - Ok, the nearest thing I can think of to what you may be suggesting is as follows: - a distance calculator interface, with methods for computing plane distance and point distance - six implementations of that interface, one for linear, normal, linear squared, normal squared, and arc - GeoOutsideDistance then has two methods: one for GeoPoint + distcalcinterface and one for (x,y,z) + distcalcinterface [~dsmiley] Is that what you were talking about? Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned SOLR-7719: - Assignee: Tommaso Teofili Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Attachments: SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2453 - Still Failing!
It might be related to my changes around deleted docs handling, I'm looking into it. On Thu, Jun 25, 2015 at 4:47 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2453/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.facet.TestDrillSideways.testRandom Error Message: expected:42 but was:44 Stack Trace: java.lang.AssertionError: expected:42 but was:44 at __randomizedtesting.SeedInfo.seed([22909B4E327EB3A5:50DCBE41831E05D6]: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.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.facet.TestDrillSideways.verifyEquals(TestDrillSideways.java:1050) at org.apache.lucene.facet.TestDrillSideways.testRandom(TestDrillSideways.java:756) 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.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 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 6661 lines...] [junit4] Suite: org.apache.lucene.facet.TestDrillSideways [junit4] 2 NOTE: reproduce with: ant test
[jira] [Commented] (LUCENE-6606) add SortingMergePolicy's sorter (if any) to SegmentInfo.toString
[ https://issues.apache.org/jira/browse/LUCENE-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601398#comment-14601398 ] ASF GitHub Bot commented on LUCENE-6606: GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/160 LUCENE-6606: add SortingMergePolicy's sorter to SegmentInfo.toString for https://issues.apache.org/jira/i#browse/LUCENE-6606 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-SegmentInfo-toString Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/160.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 #160 commit 49c8fdff29c23d1dcc62aab1cb3fabe0b03daa07 Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-06-23T14:08:30Z LUCENE-: add SortingMergePolicy's sorter (if any) to SegmentInfo.toString Also changed TestSortingMergePolicy.setUp to randomly choose regular or reverse sorting order. add SortingMergePolicy's sorter (if any) to SegmentInfo.toString Key: LUCENE-6606 URL: https://issues.apache.org/jira/browse/LUCENE-6606 Project: Lucene - Core Issue Type: Wish Reporter: Christine Poerschke Priority: Minor github pull request with proposed change to follow, it also extends TestSortingMergePolicy to randomly choose regular or reverse sorting order. -- 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-6606) add SortingMergePolicy's sorter (if any) to SegmentInfo.toString
Christine Poerschke created LUCENE-6606: --- Summary: add SortingMergePolicy's sorter (if any) to SegmentInfo.toString Key: LUCENE-6606 URL: https://issues.apache.org/jira/browse/LUCENE-6606 Project: Lucene - Core Issue Type: Wish Reporter: Christine Poerschke Priority: Minor github pull request with proposed change to follow, it also extends TestSortingMergePolicy to randomly choose regular or reverse sorting order. -- 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-6553) Simplify how we handle deleted docs in read APIs
[ https://issues.apache.org/jira/browse/LUCENE-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601540#comment-14601540 ] ASF subversion and git services commented on LUCENE-6553: - Commit 1687581 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1687581 ] LUCENE-6553: Simplify how live docs are applied. Simplify how we handle deleted docs in read APIs Key: LUCENE-6553 URL: https://issues.apache.org/jira/browse/LUCENE-6553 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6553.patch Today, all scorers and postings formats need to be able to handle deleted documents. I suspect that the reason is that we want to be able to make sure to not perform costly operations on documents that are deleted. For instance if you run a phrase query, reading positions on a document which is deleted is useless. I suspect this is also a source of inefficiencies since in some cases we apply deleted documents several times: for instance conjunctions apply deleted docs to every sub scorer. However, with the new two-phase iteration API, we have a way to make sure that we never run expensive operations on deleted documents: we could first iterate over the approximation, then check that the document is not deleted, and finally confirm the match. Since approximations are cheap, applying deleted docs after them would not be an issue. I would like to explore removing the Bits acceptDocs parameter from TermsEnum.postings, Weight.scorer, SpanWeight.getSpans and Weight.BulkScorer, and add it to BulkScorer.score. This way, bulk scorers would be the only API which would need to know how to apply deleted docs, which I think would be more manageable since we only have 3 or 4 impls. And DefaultBulkScorer would be implemented the way described above: first advance the approximation, then check deleted docs, then confirm the match, then collect. Of course that's only in the case the scorer supports approximations, if it does not, it means it is cheap so we can directly iterate the scorer and check deleted docs on top. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601577#comment-14601577 ] Michael McCandless commented on LUCENE-6578: I've only glanced at the patch so far, but abstractions are hard to get right until a given API has seen a lot of usage, and I feel like spatial module already has too many levels of abstraction now, so I think the disagreement here is good evidence that geo3d should live in sandbox for starters, where it's free to be more sandy, it can more freely iterate / change its abstractions, etc. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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-6578) Geo3d: arcDistanceToShape() method may be useful
[ https://issues.apache.org/jira/browse/LUCENE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601618#comment-14601618 ] Karl Wright commented on LUCENE-6578: - bq. I'm curious why the GeoPoint x/y/z methods are duplicated It's because I want to avoid creating a GeoPoint object simply to compute a distance. We could have just the x,y,z versions of the methods, but having the GeoPoint variant is convenient to have as well. Geo3d: arcDistanceToShape() method may be useful Key: LUCENE-6578 URL: https://issues.apache.org/jira/browse/LUCENE-6578 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: Karl Wright Attachments: LUCENE-6578.patch, LUCENE-6578.revised.patch I've got an application that seems like it may need the ability to compute a new kind of arc distance, from a GeoPoint to the nearest edge/point of a GeoShape. Adding this method to the interface, and corresponding implementations, would increase the utility of the package for ranking purposes. -- 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: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_45) - Build # 4964 - Still Failing!
I found the reason, will commit a fix shortly. On Thu, Jun 25, 2015 at 6:34 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4964/ Java: 32bit/jdk1.8.0_45 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.lucene.facet.TestDrillSideways.testRandom Error Message: expected:268 but was:271 Stack Trace: java.lang.AssertionError: expected:268 but was:271 at __randomizedtesting.SeedInfo.seed([E6398F72ADCD190:7C2FBDF89BBC67E3]: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.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.facet.TestDrillSideways.verifyEquals(TestDrillSideways.java:1050) at org.apache.lucene.facet.TestDrillSideways.testRandom(TestDrillSideways.java:756) 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.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 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 6670 lines...] [junit4] Suite: org.apache.lucene.facet.TestDrillSideways [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestDrillSideways
[jira] [Commented] (LUCENE-6553) Simplify how we handle deleted docs in read APIs
[ https://issues.apache.org/jira/browse/LUCENE-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601528#comment-14601528 ] ASF subversion and git services commented on LUCENE-6553: - Commit 1687580 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1687580 ] LUCENE-6553: Fix how DrillSidewaysScorer handles deleted docs. Simplify how we handle deleted docs in read APIs Key: LUCENE-6553 URL: https://issues.apache.org/jira/browse/LUCENE-6553 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6553.patch Today, all scorers and postings formats need to be able to handle deleted documents. I suspect that the reason is that we want to be able to make sure to not perform costly operations on documents that are deleted. For instance if you run a phrase query, reading positions on a document which is deleted is useless. I suspect this is also a source of inefficiencies since in some cases we apply deleted documents several times: for instance conjunctions apply deleted docs to every sub scorer. However, with the new two-phase iteration API, we have a way to make sure that we never run expensive operations on deleted documents: we could first iterate over the approximation, then check that the document is not deleted, and finally confirm the match. Since approximations are cheap, applying deleted docs after them would not be an issue. I would like to explore removing the Bits acceptDocs parameter from TermsEnum.postings, Weight.scorer, SpanWeight.getSpans and Weight.BulkScorer, and add it to BulkScorer.score. This way, bulk scorers would be the only API which would need to know how to apply deleted docs, which I think would be more manageable since we only have 3 or 4 impls. And DefaultBulkScorer would be implemented the way described above: first advance the approximation, then check deleted docs, then confirm the match, then collect. Of course that's only in the case the scorer supports approximations, if it does not, it means it is cheap so we can directly iterate the scorer and check deleted docs on top. -- 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-6553) Simplify how we handle deleted docs in read APIs
[ https://issues.apache.org/jira/browse/LUCENE-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601566#comment-14601566 ] ASF subversion and git services commented on LUCENE-6553: - Commit 1687586 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1687586 ] LUCENE-6553: Fixes to Weight's javadoc. Simplify how we handle deleted docs in read APIs Key: LUCENE-6553 URL: https://issues.apache.org/jira/browse/LUCENE-6553 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6553.patch Today, all scorers and postings formats need to be able to handle deleted documents. I suspect that the reason is that we want to be able to make sure to not perform costly operations on documents that are deleted. For instance if you run a phrase query, reading positions on a document which is deleted is useless. I suspect this is also a source of inefficiencies since in some cases we apply deleted documents several times: for instance conjunctions apply deleted docs to every sub scorer. However, with the new two-phase iteration API, we have a way to make sure that we never run expensive operations on deleted documents: we could first iterate over the approximation, then check that the document is not deleted, and finally confirm the match. Since approximations are cheap, applying deleted docs after them would not be an issue. I would like to explore removing the Bits acceptDocs parameter from TermsEnum.postings, Weight.scorer, SpanWeight.getSpans and Weight.BulkScorer, and add it to BulkScorer.score. This way, bulk scorers would be the only API which would need to know how to apply deleted docs, which I think would be more manageable since we only have 3 or 4 impls. And DefaultBulkScorer would be implemented the way described above: first advance the approximation, then check deleted docs, then confirm the match, then collect. Of course that's only in the case the scorer supports approximations, if it does not, it means it is cheap so we can directly iterate the scorer and check deleted docs on top. -- 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-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601435#comment-14601435 ] Joel Bernstein commented on SOLR-7560: -- ok, great. I'll switch over to the 0.108 parser. thanks! Parallel SQL Support Key: SOLR-7560 URL: https://issues.apache.org/jira/browse/SOLR-7560 Project: Solr Issue Type: New Feature Components: clients - java, search Reporter: Joel Bernstein Fix For: 5.3 Attachments: SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch This ticket provides support for executing *Parallel SQL* queries across SolrCloud collections. The SQL engine will be built on top of the Streaming API (SOLR-7082), which provides support for *parallel relational algebra* and *real-time map-reduce*. Basic design: 1) A new SQLHandler will be added to process SQL requests. The SQL statements will be compiled to live Streaming API objects for parallel execution across SolrCloud worker nodes. 2) SolrCloud collections will be abstracted as *Relational Tables*. 3) The Presto SQL parser will be used to parse the SQL statements. 4) A JDBC thin client will be added as a Solrj client. This ticket will focus on putting the framework in place and providing basic SELECT support and GROUP BY aggregate support. Future releases will build on this framework to provide additional SQL features. -- 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
