[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_112) - Build # 6307 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6307/ Java: 32bit/jdk1.8.0_112 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.metrics.JvmMetricsTest.testOperatingSystemMetricsSet Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([77E80C46EDB7D323:6F17683314B18876]: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.metrics.JvmMetricsTest.testOperatingSystemMetricsSet(JvmMetricsTest.java:51) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10726 lines...] [junit4] Suite: org.apache.solr.metrics.JvmMetricsTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.metrics.JvmMetricsTest_77E80C46EDB7D323-001\init-core-data-001
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 571 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/571/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancelFail Error Message: expected:<200> but was:<404> Stack Trace: java.lang.AssertionError: expected:<200> but was:<404> at __randomizedtesting.SeedInfo.seed([1D2965CFA64904A1:759650E576D3164D]: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.solr.security.hadoop.TestDelegationWithHadoopAuth.cancelDelegationToken(TestDelegationWithHadoopAuth.java:128) at org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancelFail(TestDelegationWithHadoopAuth.java:289) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 595 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/595/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test
Error Message:
Expected 2 of 3 replicas to be active but only found 1;
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:60169/_x","node_name":"127.0.0.1:60169__x","state":"active","leader":"true"}];
clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/32)={
"replicationFactor":"3", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node1":{ "core":"c8n_1x3_lf_shard1_replica2",
"base_url":"http://127.0.0.1:60181/_x;,
"node_name":"127.0.0.1:60181__x", "state":"down"},
"core_node2":{ "state":"down",
"base_url":"http://127.0.0.1:60148/_x;,
"core":"c8n_1x3_lf_shard1_replica3",
"node_name":"127.0.0.1:60148__x"}, "core_node3":{
"core":"c8n_1x3_lf_shard1_replica1",
"base_url":"http://127.0.0.1:60169/_x;,
"node_name":"127.0.0.1:60169__x", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false"}
Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found
1;
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:60169/_x","node_name":"127.0.0.1:60169__x","state":"active","leader":"true"}];
clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/32)={
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node1":{
"core":"c8n_1x3_lf_shard1_replica2",
"base_url":"http://127.0.0.1:60181/_x;,
"node_name":"127.0.0.1:60181__x",
"state":"down"},
"core_node2":{
"state":"down",
"base_url":"http://127.0.0.1:60148/_x;,
"core":"c8n_1x3_lf_shard1_replica3",
"node_name":"127.0.0.1:60148__x"},
"core_node3":{
"core":"c8n_1x3_lf_shard1_replica1",
"base_url":"http://127.0.0.1:60169/_x;,
"node_name":"127.0.0.1:60169__x",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"}
at
__randomizedtesting.SeedInfo.seed([ACF49560801DA0:88F8CB4FCE7C7058]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 654 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/654/ No tests ran. Build Log: [...truncated 41962 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 260 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (19.8 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.0.0-src.tgz... [smoker] 30.5 MB in 0.03 sec (879.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.tgz... [smoker] 64.9 MB in 0.08 sec (830.1 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.zip... [smoker] 75.8 MB in 0.09 sec (860.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6156 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6156 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 214 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.00 sec (212.7 MB/sec) [smoker] check changes HTML... [smoker] download solr-7.0.0-src.tgz... [smoker] 40.0 MB in 0.05 sec (824.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.tgz... [smoker] 140.3 MB in 0.17 sec (820.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.zip... [smoker] 149.8 MB in 0.18 sec (821.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-7.0.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8 [smoker] Creating Solr home directory /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] bin/solr start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [smoker] Started Solr server on port 8983 (pid=21788). Happy searching! [smoker]
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_112) - Build # 2495 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2495/
Java: 32bit/jdk1.8.0_112 -client -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt.testBasics
Error Message:
Address already in use
Stack Trace:
java.net.BindException: Address already in use
at
__randomizedtesting.SeedInfo.seed([C1EF7A8B2C8CB00C:FC37D4A71462EE7C]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
at
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Build Log:
[...truncated 12399 lines...]
[junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt
[junit4] 2> 1765396 WARN
(TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[C1EF7A8B2C8CB00C]) []
o.a.d.s.c.DefaultDirectoryService You didn't change the admin password of
directory service instance 'DefaultKrbServer'. Please update the admin
password as soon as possible to prevent a possible security breach.
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestSolrCloudWithKerberosAlt -Dtests.method=testBasics
-Dtests.seed=C1EF7A8B2C8CB00C -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=und -Dtests.timezone=SystemV/MST7 -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 10.9s J0 | TestSolrCloudWithKerberosAlt.testBasics <<<
[junit4]> Throwable #1: java.net.BindException: Address already in use
[junit4]>at
__randomizedtesting.SeedInfo.seed([C1EF7A8B2C8CB00C:FC37D4A71462EE7C]:0)
[junit4]>at sun.nio.ch.Net.bind0(Native Method)
[junit4]>at sun.nio.ch.Net.bind(Net.java:433)
[junit4]>at sun.nio.ch.Net.bind(Net.java:425)
[junit4]>at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
[junit4]>at
sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
[junit4]>at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
[junit4]>at
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
[junit4]>at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
[junit4]>at
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
[junit4]>at
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
[junit4]>at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit4]>at java.lang.Thread.run(Thread.java:745)
[junit4] 2> NOTE: leaving temporary files on disk at:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithKerberosAlt_C1EF7A8B2C8CB00C-001
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene62): {},
docValues:{}, maxPointsInLeafNode=1640, maxMBSortInHeap=5.2385463008873225,
sim=RandomSimilarity(queryNorm=true,coord=yes): {}, locale=und,
timezone=SystemV/MST7
[junit4] 2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 1.8.0_112
(32-bit)/cpus=12,threads=1,free=144026008,total=505413632
[junit4] 2> NOTE: All tests run in this JVM:
[TestEmbeddedSolrServerConstructors, SimpleMLTQParserTest, HLLUtilTest,
TestComponentsName, SmileWriterTest, TestNRTOpen, HdfsLockFactoryTest,
CoreMergeIndexesAdminHandlerTest, TestPKIAuthenticationPlugin,
TriLevelCompositeIdRoutingTest, TestBlobHandler, TestFieldTypeResource,
RuleEngineTest, ZkStateReaderTest, TestJmxIntegration, TestDistributedSearch,
TestFieldCacheReopen, ExternalFileFieldSortTest,
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773821#comment-15773821
]
Judith Silverman commented on SOLR-6203:
Hi, I see, you are separating the refactoring from the bug fix. I like the new
name and the new place.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
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-9805) Use metrics-jvm library to instrument jvm internals
[ https://issues.apache.org/jira/browse/SOLR-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773770#comment-15773770 ] ASF subversion and git services commented on SOLR-9805: --- Commit 687f03661d726d70d5718db8b45990b3fbc98183 in lucene-solr's branch refs/heads/master from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=687f036 ] SOLR-9805 Fix NPE. > Use metrics-jvm library to instrument jvm internals > --- > > Key: SOLR-9805 > URL: https://issues.apache.org/jira/browse/SOLR-9805 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9805.patch, jvm-metrics.xml > > Original Estimate: 24h > Remaining Estimate: 24h > > See http://metrics.dropwizard.io/3.1.0/manual/jvm/ -- 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-master-Windows (64bit/jdk1.8.0_112) - Build # 6306 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6306/ Java: 64bit/jdk1.8.0_112 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.metrics.JvmMetricsTest.testOperatingSystemMetricsSet Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([7DAFA6C7A4EA4D17:6550C2B25DEC1642]:0) at org.apache.solr.metrics.JvmMetricsTest.testOperatingSystemMetricsSet(JvmMetricsTest.java:50) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11333 lines...] [junit4] Suite: org.apache.solr.metrics.JvmMetricsTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.metrics.JvmMetricsTest_7DAFA6C7A4EA4D17-001\init-core-data-001 [junit4] 2> 859922 INFO (SUITE-JvmMetricsTest-seed#[7DAFA6C7A4EA4D17]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and
[jira] [Created] (SOLR-9891) bin/solr cannot create an empty Znode which is useful for chroot
Erick Erickson created SOLR-9891: Summary: bin/solr cannot create an empty Znode which is useful for chroot Key: SOLR-9891 URL: https://issues.apache.org/jira/browse/SOLR-9891 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor This came to my attention just now. To use a different root in Solr, we say this in the ref guide: IMPORTANT: If your ZooKeeper connection string uses a chroot, such as localhost:2181/solr, then you need to bootstrap the /solr znode before launching SolrCloud using the bin/solr script. To do this, you need to use the zkcli.sh script shipped with Solr, such as: server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181/solr -cmd bootstrap -solrhome server/solr I think all this really does is create an empty /solr ZNode. We're trying to move the common usages of the zkcli scripts to bin/solr so I tried making this work. It's clumsy. If I try to copy up an empty directory to /solr nothing happens. I got it to work by copying file:README.txt to zk:/solr/nonsense then delete zk:/solr/nonsense. Ugly. I don't want to get into reproducing the whole Unix shell file manipulation commands with mkdir, touch, etc. I guess we already have special 'upconfig' and 'downconfig' commands, so maybe a specific command for this like 'mkroot' would be OK. Do people have opinions about this as opposed to 'mkdir'? I'm tending to mkdir. Or have the cp command handle empty directories, but mkroot/mkdir seems more intuitive if not as generic. -- 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-9448) [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773633#comment-15773633
]
Mikhail Khludnev edited comment on SOLR-9448 at 12/23/16 8:41 PM:
--
attaching simpler approach to reproduce:
{code}
15551 ERROR (qtp1315527986-39) [n:127.0.0.1:56344_solr c:people s:shard2
r:core_node1 x:people_shard2_replica1] o.a.s.h.RequestHandlerBase
java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1118)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:763)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:742)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:422)
{code}
was (Author: mkhludnev):
attaching simpler approach to reproduce:
{code}
9741 ERROR (qtp1940230238-41) [n:127.0.0.1:55195_solr c:departments s:shard1
r:core_node4 x:departments_shard1_replica1] o.a.s.s.HttpSolrCall
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:294)
{code}
> [subquery] calls another collection fails with "undefined field" or NPE from
> mergeIds
> -
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.1, 6.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch, SOLR-9448.patch, SOLR-9448.patch
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is
> described in the first comment. It seems like
> fl=foo:\[subquery]=bar can be fixed just by declaring fields in
> schema.
> h3. Old description
> straightforward \[subquery] implementation executes requests on a caller
> collection, but just hitting another one with
> {{caller/select?q=..=callee}}. The problem is that for
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one.
> Another observation, at that case both single sharded collections are
> collocated at the same instance. Then, subquery can't be parsed if it queries
> a field which are absent in caller schema. All of this seems pretty strange
> like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
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-9448) [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9448:
---
Attachment: SOLR-9448.patch
> [subquery] calls another collection fails with "undefined field" or NPE from
> mergeIds
> -
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.1, 6.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch, SOLR-9448.patch, SOLR-9448.patch
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is
> described in the first comment. It seems like
> fl=foo:\[subquery]=bar can be fixed just by declaring fields in
> schema.
> h3. Old description
> straightforward \[subquery] implementation executes requests on a caller
> collection, but just hitting another one with
> {{caller/select?q=..=callee}}. The problem is that for
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one.
> Another observation, at that case both single sharded collections are
> collocated at the same instance. Then, subquery can't be parsed if it queries
> a field which are absent in caller schema. All of this seems pretty strange
> like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
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-9448) [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9448:
---
Attachment: (was: SOLR-9448.patch)
> [subquery] calls another collection fails with "undefined field" or NPE from
> mergeIds
> -
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.1, 6.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch, SOLR-9448.patch, SOLR-9448.patch
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is
> described in the first comment. It seems like
> fl=foo:\[subquery]=bar can be fixed just by declaring fields in
> schema.
> h3. Old description
> straightforward \[subquery] implementation executes requests on a caller
> collection, but just hitting another one with
> {{caller/select?q=..=callee}}. The problem is that for
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one.
> Another observation, at that case both single sharded collections are
> collocated at the same instance. Then, subquery can't be parsed if it queries
> a field which are absent in caller schema. All of this seems pretty strange
> like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
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-9448) [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9448:
---
Attachment: SOLR-9448.patch
attaching simpler approach to reproduce:
{code}
9741 ERROR (qtp1940230238-41) [n:127.0.0.1:55195_solr c:departments s:shard1
r:core_node4 x:departments_shard1_replica1] o.a.s.s.HttpSolrCall
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:294)
{code}
> [subquery] calls another collection fails with "undefined field" or NPE from
> mergeIds
> -
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 6.1, 6.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch, SOLR-9448.patch, SOLR-9448.patch
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is
> described in the first comment. It seems like
> fl=foo:\[subquery]=bar can be fixed just by declaring fields in
> schema.
> h3. Old description
> straightforward \[subquery] implementation executes requests on a caller
> collection, but just hitting another one with
> {{caller/select?q=..=callee}}. The problem is that for
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one.
> Another observation, at that case both single sharded collections are
> collocated at the same instance. Then, subquery can't be parsed if it queries
> a field which are absent in caller schema. All of this seems pretty strange
> like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
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-NightlyTests-6.x - Build # 235 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/235/ 2 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.testSpecificConfigsets Error Message: KeeperErrorCode = NoNode for /collections/withconfigset2 Stack Trace: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /collections/withconfigset2 at __randomizedtesting.SeedInfo.seed([17C0F5DD0EEBFFF0:3ABEBA87F9CF45FC]:0) at org.apache.zookeeper.KeeperException.create(KeeperException.java:111) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356) at org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testSpecificConfigsets(CollectionsAPIDistributedZkTest.java:425) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
[jira] [Updated] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9725:
---
Attachment: SOLR-9725.patch
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
> Attachments: SOLR-9725.patch
>
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9725:
---
Attachment: (was: SOLR-9725.patch)
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
> Attachments: SOLR-9725.patch
>
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-9843) Fix up DocValuesNotIndexedTest failures
[ https://issues.apache.org/jira/browse/SOLR-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773464#comment-15773464 ] Erick Erickson commented on SOLR-9843: -- I haven't seen any test failures lately. Nothing in the extra logging I checked in "should have changed anything". Given what I found earlier, I don't think the test failures were either a problem with the test or the code. So I'll wave my hands and say "something someone else fixed must have fixed the underlying problem". If there aren't any failures by Jan I'll just take out the extra logging and close this. Probably take out the system variable restore rule since it's apparently unnecessary too. > Fix up DocValuesNotIndexedTest failures > --- > > Key: SOLR-9843 > URL: https://issues.apache.org/jira/browse/SOLR-9843 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-9843.patch, fail.txt, shard3_replica1.txt, > shard_3_searchers.txt > > > I'll have to do a few iterations on the Jenkins builds since I can't get this > to fail locally. Marking as "blocker" since I'll probably have to put some > extra code in that I want to be sure is removed before we cut any new > releases. -- 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-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)
[ https://issues.apache.org/jira/browse/SOLR-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773399#comment-15773399 ] Judith Silverman commented on SOLR-9660: Hi, Christine, it's good to see all the updates! I haven't had time to do more than skim but I see that SOLR-9660 has been resolved with no new patches since 29Nov and I wanted to make sure that you saw my comment from 02Dec under SOLR-6203 about one of the patches for SOLR-9660. Maybe that's a non-issue or you are addressing it separately. Thanks, Judith > in GroupingSpecification factor [group](sort|offset|limit) into > [group](sortSpec) > - > > Key: SOLR-9660 > URL: https://issues.apache.org/jira/browse/SOLR-9660 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, > SOLR-9660.patch > > > This is split out and adapted from and towards the SOLR-6203 changes. -- 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-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)
[ https://issues.apache.org/jira/browse/SOLR-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved SOLR-9660. --- Resolution: Fixed Fix Version/s: master (7.0) 6.x Thanks Judith! > in GroupingSpecification factor [group](sort|offset|limit) into > [group](sortSpec) > - > > Key: SOLR-9660 > URL: https://issues.apache.org/jira/browse/SOLR-9660 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, > SOLR-9660.patch > > > This is split out and adapted from and towards the SOLR-6203 changes. -- 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-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+147) - Build # 18599 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18599/ Java: 64bit/jdk-9-ea+147 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail Error Message: expected:<200> but was:<404> Stack Trace: java.lang.AssertionError: expected:<200> but was:<404> at __randomizedtesting.SeedInfo.seed([9D89BA70282186EE:F5368F5AF8BB9402]: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.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Comment Edited] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773344#comment-15773344 ] Joel Bernstein edited comment on SOLR-8593 at 12/23/16 5:41 PM: I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned data in the fields. I now believe that is not the case, because we've pushed down the *projection*. Because we've pushed down the projection we'll need to implement the arithmetic and string functions using the *SelectStream*. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. was (Author: joel.bernstein): I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned data in the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the *projection* we'll need to implement the arithmetic and string functions using the *SelectStream*. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8593.patch, SOLR-8593.patch > > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)
[ https://issues.apache.org/jira/browse/SOLR-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773351#comment-15773351 ] ASF subversion and git services commented on SOLR-9660: --- Commit 038d4514a787d4137c59322dd38218eaa5be291a in lucene-solr's branch refs/heads/branch_6x from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=038d451 ] SOLR-9660: rename GroupSpecification's sortSpecWithinGroup to withinGroupSortSpec (Judith Silverman via Christine Poerschke) > in GroupingSpecification factor [group](sort|offset|limit) into > [group](sortSpec) > - > > Key: SOLR-9660 > URL: https://issues.apache.org/jira/browse/SOLR-9660 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, > SOLR-9660.patch > > > This is split out and adapted from and towards the SOLR-6203 changes. -- 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-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773344#comment-15773344 ] Joel Bernstein edited comment on SOLR-8593 at 12/23/16 5:40 PM: I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned data in the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the *projection* we'll need to implement the arithmetic and string functions using the *SelectStream*. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. was (Author: joel.bernstein): I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned data in the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the projection we'll need to implement the arithmetic and string functions using the SelectStream. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8593.patch, SOLR-8593.patch > > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773348#comment-15773348
]
Christine Poerschke commented on SOLR-6203:
---
bq. ... new utility functions (which turned out to be identical ... combined
and put in a good place ...
SOLR-9890 proposes a combined version in a new place. What do you think?
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
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-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773344#comment-15773344 ] Joel Bernstein edited comment on SOLR-8593 at 12/23/16 5:38 PM: I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned data in the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the projection we'll need to implement the arithmetic and string functions using the SelectStream. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. was (Author: joel.bernstein): I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the projection we'll need to implement the arithmetic and string functions using the SelectStream. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8593.patch, SOLR-8593.patch > > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773344#comment-15773344 ] Joel Bernstein commented on SOLR-8593: -- I think I have a handle now on how the *string* and *arithmetic* functions work. I was expecting them to work automatically and Calcite would perform the functions if we returned the fields. I now believe that is not the case, because we've pushed down the projection. Because we've pushed down the projection we'll need to implement the arithmetic and string functions using the SelectStream. What Calcite provides in the project rule is access to the parse tree so we have enough information to implement the functions. Since this ticket was mainly about getting parity with the current SQL functionality, I think it makes sense to tackle the string and arithmetic functions in a separate ticket. I will create that ticket. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8593.patch, SOLR-8593.patch > > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9890) factor out ShardResultTransformerUtils.[un]marshSortValue methods
[
https://issues.apache.org/jira/browse/SOLR-9890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-9890:
--
Attachment: SOLR-9890.patch
This patch here is split out and adapted from [~Judith]'s (Dec 5th) SOLR-6203
patch, the {{\[un\]marshalSortValue}} methods here combine the two
{{convertSortValue}} methods in that patch.
Comments and reviews welcome, thank you.
> factor out ShardResultTransformerUtils.[un]marshSortValue methods
> -
>
> Key: SOLR-9890
> URL: https://issues.apache.org/jira/browse/SOLR-9890
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9890.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9890) factor out ShardResultTransformerUtils.[un]marshSortValue methods
Christine Poerschke created SOLR-9890: - Summary: factor out ShardResultTransformerUtils.[un]marshSortValue methods Key: SOLR-9890 URL: https://issues.apache.org/jira/browse/SOLR-9890 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor -- 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-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773321#comment-15773321
]
Christine Poerschke commented on SOLR-6203:
---
bq. ... since we are already deprecating GroupingSpecification's accessors for
Sorts in favor of accessors of SortSpecs, this seems to me like a good time to
make the change. I renamed the new public accessors ...
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc8936a just added
the rename under the SOLR-9660 ticket which as you say was already concerned
with those accessors.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
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-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)
[ https://issues.apache.org/jira/browse/SOLR-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773307#comment-15773307 ] ASF subversion and git services commented on SOLR-9660: --- Commit bc8936a567e40eef3b70665fd8838548350c9aaa in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc8936a ] SOLR-9660: rename GroupSpecification's sortSpecWithinGroup to withinGroupSortSpec (Judith Silverman via Christine Poerschke) > in GroupingSpecification factor [group](sort|offset|limit) into > [group](sortSpec) > - > > Key: SOLR-9660 > URL: https://issues.apache.org/jira/browse/SOLR-9660 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, > SOLR-9660.patch > > > This is split out and adapted from and towards the SOLR-6203 changes. -- 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-9883) example solr config files can lead to invalid tlog replays when using add-unknown-fields-to-schema updat chain
[ https://issues.apache.org/jira/browse/SOLR-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reassigned SOLR-9883: Assignee: Steve Rowe > example solr config files can lead to invalid tlog replays when using > add-unknown-fields-to-schema updat chain > -- > > Key: SOLR-9883 > URL: https://issues.apache.org/jira/browse/SOLR-9883 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.3, trunk >Reporter: Erick Erickson >Assignee: Steve Rowe > > The current basic_configs and data_driven_schema_configs try to create > unknown fields. The problem is that the date processing > "ParseDateFieldUpdateProcessorFactory" is not invoked if the doc is replayed > from the tlog. Whether there are other places this is a problem I don't know, > this is a concrete example that fails in the field. > So say I have a pattern for dates that omits the trialing 'Z', as: > -MM-dd'T'HH:mm:ss.SSS > This work fine when the doc is initially indexed. Now say the doc must be > replayed from the tlog. The doc errors out with "unknown date format" since > (apparently) this doesn't go through the same update chain, perhaps due to > the sample configs defining ParseDateFieldUpdateProcessorFactory after > DistributedUpdateProcessorFactory? -- 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-7055) Better execution path for costly queries
[ https://issues.apache.org/jira/browse/LUCENE-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-7055: - Attachment: LUCENE-7055.patch I have been looking at slow queries recently, which were slow for that exact reason. They were running a point range query that covered most of the index, intersected with selective queries, which is typically the case when doc values would perform better than points. So I started exploring how we could improve this and got the following: - PointValues get a new method that computes an estimate of the cost of a visitor. For the Lucene70 codec it basically counts the numbers of leaf blocks that intersect the visitor, and multiplies that number by the number of points on leaf blocks. - A new API on Weight allows to get an estimate of the cost of a Scorer before building it. The underlying idea is that in the case of a conjunction that contains a range, the range should use points if it has the least cost (ie. it will lead the iteration) and doc values otherwise since the scorer will only be used to validate that the current document matched. I attached a patch if someone is interested to look into how that works. I tried to make it as little invasive as possible: the new API on Weight is optional, and we do not need to implement giant queries that know both how to use points and doc values, instead there is a wrapper query called IndexOrDocValuesQuery that wraps both a point/index query and a doc values query and it figures out which one to use based on costs. It is neither complete not commitable, just a proof of concept to trigger some discussion. > Better execution path for costly queries > > > Key: LUCENE-7055 > URL: https://issues.apache.org/jira/browse/LUCENE-7055 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Attachments: LUCENE-7055.patch > > > In Lucene 5.0, we improved the execution path for queries that run costly > operations on a per-document basis, like phrase queries or doc values > queries. But we have another class of costly queries, that return fine > iterators, but these iterators are very expensive to build. This is typically > the case for queries that leverage DocIdSetBuilder, like TermsQuery, > multi-term queries or the new point queries. Intersecting such queries with a > selective query is very inefficient since these queries build a doc id set of > matching documents for the entire index. > Is there something we could do to improve the execution path for these > queries? > One idea that comes to mind is that most of these queries could also run on > doc values, so maybe we could come up with something that would help decide > how to run a query based on other parts of the query? (Just thinking out > loud, other ideas are very welcome) -- 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] [Closed] (LUCENE-5445) factor out abstract base class EarlySegmentTerminatingCollector and change existing EarlyTerminatingSortingCollector to inherit from it
[
https://issues.apache.org/jira/browse/LUCENE-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke closed LUCENE-5445.
---
Resolution: Later
Closing out old ticket, no changes made, might be done later/in future perhaps.
> factor out abstract base class EarlySegmentTerminatingCollector and change
> existing EarlyTerminatingSortingCollector to inherit from it
> ---
>
> Key: LUCENE-5445
> URL: https://issues.apache.org/jira/browse/LUCENE-5445
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Solr has an {noformat}EarlyTerminatingCollector{noformat} which operates
> across segments, a Lucene abstract base class
> {noformat}EarlySegmentTerminatingCollector{noformat} (or some other name)
> could make the distinction between the two terminating collector varieties
> clearer.
--
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-7530) extend/add -validate-source-patterns checks for .xml/.template files
[ https://issues.apache.org/jira/browse/LUCENE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773098#comment-15773098 ] Christine Poerschke commented on LUCENE-7530: - Yes it can. Precommit had passed and in the (unlikely) case of Jenkins still flagging something up it can always be re-opened. > extend/add -validate-source-patterns checks for .xml/.template files > > > Key: LUCENE-7530 > URL: https://issues.apache.org/jira/browse/LUCENE-7530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: 6.x, master (7.0) > > Attachments: LUCENE-7530.patch, LUCENE-7530.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7530) extend/add -validate-source-patterns checks for .xml/.template files
[ https://issues.apache.org/jira/browse/LUCENE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved LUCENE-7530. - Resolution: Fixed Fix Version/s: master (7.0) 6.x > extend/add -validate-source-patterns checks for .xml/.template files > > > Key: LUCENE-7530 > URL: https://issues.apache.org/jira/browse/LUCENE-7530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: 6.x, master (7.0) > > Attachments: LUCENE-7530.patch, LUCENE-7530.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7530) extend/add -validate-source-patterns checks for .xml/.template files
[ https://issues.apache.org/jira/browse/LUCENE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773087#comment-15773087 ] Michael McCandless commented on LUCENE-7530: Can this be closed now [~cpoerschke]? > extend/add -validate-source-patterns checks for .xml/.template files > > > Key: LUCENE-7530 > URL: https://issues.apache.org/jira/browse/LUCENE-7530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-7530.patch, LUCENE-7530.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3728 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3728/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 70094 lines...] [javadoc] # A fatal error has been detected by the Java Runtime Environment: [javadoc] # [javadoc] [thread 18179 also had an error] [javadoc] # SIGFPE (0x8) at pc=0x7fff953c6143, pid=778, tid=0x4303 [javadoc] # [javadoc] # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0_102-b14) [javadoc] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode bsd-amd64 compressed oops) [javadoc] # Problematic frame: [javadoc] # C [libsystem_kernel.dylib+0x11143] __commpage_gettimeofday+0x43 [javadoc] # [javadoc] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [javadoc] # [javadoc] # An error report file with more information is saved as: [javadoc] # /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/hs_err_pid778.log [javadoc] # [javadoc] # If you would like to submit a bug report, please visit: [javadoc] # http://bugreport.java.com/bugreport/crash.jsp [javadoc] # BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:775: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:651: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:498: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:463: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler-extras/build.xml:72: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:305: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2100: Javadoc returned 134 Total time: 107 minutes 37 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE 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] (SOLR-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773039#comment-15773039 ] ASF subversion and git services commented on SOLR-8542: --- Commit b7c75a3a1c7524994cb2413afa82562e30eaadcb in lucene-solr's branch refs/heads/branch_6x from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b7c75a3 ] SOLR-8542: change default feature vector format (to 'dense' from 'sparse') also: increase test coverage w.r.t. 'sparse' vs. 'dense' vs. 'default' feature vector format > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- 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-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+147) - Build # 18598 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18598/ Java: 32bit/jdk-9-ea+147 -server -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail Error Message: expected:<200> but was:<404> Stack Trace: java.lang.AssertionError: expected:<200> but was:<404> at __randomizedtesting.SeedInfo.seed([2D1E191A38A4381B:45A12C30E83E2AF7]: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.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:304) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773020#comment-15773020
]
Kristine Jetzke commented on SOLR-9725:
---
Ah, ok, sounds good. I didn't check the actual content of the patch/didn't test
the behavior though.
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
> Attachments: SOLR-9725.patch
>
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772997#comment-15772997
]
Mikhail Khludnev commented on SOLR-9725:
I had difficulties in applying the patch proposed earlier, after reading your
comment I might conclude that it was caused by the fact that it was generated
on 5x. The rule of thumb is to commit to master and 6x by default. There will
be probably no 5.x releases anyway. Are you ok with [^SOLR-9725.patch] for
master and 6x. Once again, 5x makes no sense to bother at all.
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
> Attachments: SOLR-9725.patch
>
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772963#comment-15772963
]
Kristine Jetzke commented on SOLR-9725:
---
[~mkhludnev] Do you mean with "lay smoothly" that the patch cannot be applied
or that there is a problem with what it's doing (Sorry, I'm not a native
speaker...) If it's the former: The patch only works against master, not
against the 5x branch because only master contains SOLR-8610. What is the
desired fix version anyway?
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Assignee: Mikhail Khludnev
>Priority: Minor
> Labels: patch
> Attachments: SOLR-9725.patch
>
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772965#comment-15772965 ] ASF subversion and git services commented on SOLR-8542: --- Commit f62874e47a0c790b9e396f58ef6f14ea04e2280b in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f62874e ] SOLR-8542: change default feature vector format (to 'dense' from 'sparse') also: increase test coverage w.r.t. 'sparse' vs. 'dense' vs. 'default' feature vector format > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- 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-9787) Replace json.nl=arrnvp with json.nl=arrntv (array of Name Type Value) style in JSONResponseWriter
[
https://issues.apache.org/jira/browse/SOLR-9787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonny Marks updated SOLR-9787:
--
Attachment: SOLR-9787.patch
arrntv patch attached
> Replace json.nl=arrnvp with json.nl=arrntv (array of Name Type Value) style
> in JSONResponseWriter
> -
>
> Key: SOLR-9787
> URL: https://issues.apache.org/jira/browse/SOLR-9787
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9787.patch, SOLR-9787.patch
>
>
> This follows on from and builds upon SOLR-9442's addition of json.nl=arrnvp
> style. See
> https://issues.apache.org/jira/browse/SOLR-9442?focusedCommentId=15664719=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15664719
> onwards for background info.
> Example:
> {code}
> NamedList("a"=1,"bar”=“foo",null=3.4f,null=null)
> =>
> [
> { "name":"a", "type":"int", "value":1 },
> { "name":"bar", "type":"str", "value":"foo" },
> { "name":null, "type":"float", "value":3.4 },
> { "name":null, "type":"null", "value":null }
> ]
> {code}
> This style maintains the type information of the values, similar to the xml
> format:
> {code}
>
> 1
> foo
> 3.4
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1190 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1190/ 6 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testTargetCollectionNotAvailable Error Message: Timeout while trying to assert replication errors Stack Trace: java.lang.AssertionError: Timeout while trying to assert replication errors at __randomizedtesting.SeedInfo.seed([AAC8E16D485A2214:4C5CBB1E43054F3C]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testTargetCollectionNotAvailable(CdcrReplicationDistributedZkTest.java:145) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.AssertionError at
[jira] [Commented] (SOLR-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772880#comment-15772880 ] ASF subversion and git services commented on SOLR-8542: --- Commit 01846cbb4ccfdc9237cbd0af631b8d000448b0f8 in lucene-solr's branch refs/heads/branch_6x from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=01846cb ] SOLR-8542: reduce direct solrconfig-ltr.xml references in solr/contrib/ltr tests > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- 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-8542) Integrate Learning to Rank into Solr
[ https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772851#comment-15772851 ] ASF subversion and git services commented on SOLR-8542: --- Commit ac3f1bb339df530d6d4484f26c9ab2da17bd28df in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ac3f1bb ] SOLR-8542: reduce direct solrconfig-ltr.xml references in solr/contrib/ltr tests > Integrate Learning to Rank into Solr > > > Key: SOLR-8542 > URL: https://issues.apache.org/jira/browse/SOLR-8542 > Project: Solr > Issue Type: New Feature >Reporter: Joshua Pantony >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8542-branch_5x.patch, SOLR-8542-trunk.patch, > SOLR-8542.patch > > > This is a ticket to integrate learning to rank machine learning models into > Solr. Solr Learning to Rank (LTR) provides a way for you to extract features > directly inside Solr for use in training a machine learned model. You can > then deploy that model to Solr and use it to rerank your top X search > results. This concept was previously [presented by the authors at Lucene/Solr > Revolution > 2015|http://www.slideshare.net/lucidworks/learning-to-rank-in-solr-presented-by-michael-nilsson-diego-ceccarelli-bloomberg-lp]. > [Read through the > README|https://github.com/bloomberg/lucene-solr/tree/master-ltr-plugin-release/solr/contrib/ltr] > for a tutorial on using the plugin, in addition to how to train your own > external model. -- 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-7530) extend/add -validate-source-patterns checks for .xml/.template files
[ https://issues.apache.org/jira/browse/LUCENE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772842#comment-15772842 ] ASF subversion and git services commented on LUCENE-7530: - Commit 869322434941893a6f4c92af64034e9143f667bc in lucene-solr's branch refs/heads/branch_6x from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8693224 ] LUCENE-7530: extend/add -validate-source-patterns checks for .xml/.template files > extend/add -validate-source-patterns checks for .xml/.template files > > > Key: LUCENE-7530 > URL: https://issues.apache.org/jira/browse/LUCENE-7530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-7530.patch, LUCENE-7530.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7530) extend/add -validate-source-patterns checks for .xml/.template files
[ https://issues.apache.org/jira/browse/LUCENE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772804#comment-15772804 ] ASF subversion and git services commented on LUCENE-7530: - Commit f7ea2ae85db39f12709c3341d57efa28a56bf976 in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f7ea2ae ] LUCENE-7530: extend/add -validate-source-patterns checks for .xml/.template files > extend/add -validate-source-patterns checks for .xml/.template files > > > Key: LUCENE-7530 > URL: https://issues.apache.org/jira/browse/LUCENE-7530 > Project: Lucene - Core > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-7530.patch, LUCENE-7530.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_112) - Build # 6305 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6305/ Java: 32bit/jdk1.8.0_112 -server -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail Error Message: expected:<200> but was:<404> Stack Trace: java.lang.AssertionError: expected:<200> but was:<404> at __randomizedtesting.SeedInfo.seed([B522941EC793441B:DD9DA134170956F7]: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.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-7401) BKDWriter should ensure all dimensions are indexed
[ https://issues.apache.org/jira/browse/LUCENE-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772565#comment-15772565 ] Michael McCandless commented on LUCENE-7401: +1, I like how simple the implementation is, just tracking how many times each dim was split "above" us. > BKDWriter should ensure all dimensions are indexed > -- > > Key: LUCENE-7401 > URL: https://issues.apache.org/jira/browse/LUCENE-7401 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7401.patch > > > The current heuristic is to use the dimension that has the largest span, so > if dimensions have a different distribution of values, we could theoretically > (but maybe in practice too?) end up with one dimension that is not indexed at > all and queries that are mostly selective on this dimension would need to > scan lots of blocks. -- 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] [Issue Comment Deleted] (SOLR-8542) Integrate Learning to Rank into Solr
[
https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
adeppa updated SOLR-8542:
-
Comment: was deleted
(was: Hi Team,
while deploying feature into feature store getting error like below ,current
environment is solr 6 with branch_6x commit of LTR
BAN7265:solr-6.3.0-setup athondur$ curl -XPUT
'http://localhost:8983/solr/drupal/schema/feature-store' --data-binary "@
./Users/athondur/Desktop/solr_6.3/solr-6.3.0-setup/contrib/ltr/example/techproducts-features.json"
-H 'Content-type:application/json'
Warning: Couldn't read data from file "
Warning: ./Users/athondur/Desktop/solr_6.3/solr-6.3.0-setup/contrib/ltr/example
Warning: /techproducts-features.json", this makes an empty POST.
{
"responseHeader":{
"status":500,
"QTime":3},
"error":{
"msg":"Bad Request",
"trace":"Bad Request (400) - Empty request body!\n\tat
org.apache.solr.rest.RestManager$ManagedEndpoint.parseJsonFromRequestBody(RestManager.java:420)\n\tat
org.apache.solr.rest.RestManager$ManagedEndpoint.put(RestManager.java:340)\n\tat
org.restlet.resource.ServerResource.doHandle(ServerResource.java:447)\n\tat
org.restlet.resource.ServerResource.doConditionalHandle(ServerResource.java:359)\n\tat
org.restlet.resource.ServerResource.handle(ServerResource.java:1044)\n\tat
org.restlet.resource.Finder.handle(Finder.java:236)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:140)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)\n\tat
org.restlet.engine.application.ApplicationHelper.handle(ApplicationHelper.java:75)\n\tat
org.restlet.Application.handle(Application.java:385)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)\n\tat
org.restlet.Component.handle(Component.java:408)\n\tat
org.restlet.Server.handle(Server.java:507)\n\tat
org.restlet.engine.connector.ServerHelper.handle(ServerHelper.java:63)\n\tat
org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:143)\n\tat
org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:1117)\n\tat
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:199)\n\tat
org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:74)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:312)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
[jira] [Commented] (SOLR-8542) Integrate Learning to Rank into Solr
[
https://issues.apache.org/jira/browse/SOLR-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15772544#comment-15772544
]
adeppa commented on SOLR-8542:
--
Hi Team,
while deploying feature into feature store getting error like below ,current
environment is solr 6 with branch_6x commit of LTR
BAN7265:solr-6.3.0-setup athondur$ curl -XPUT
'http://localhost:8983/solr/drupal/schema/feature-store' --data-binary "@
./Users/athondur/Desktop/solr_6.3/solr-6.3.0-setup/contrib/ltr/example/techproducts-features.json"
-H 'Content-type:application/json'
Warning: Couldn't read data from file "
Warning: ./Users/athondur/Desktop/solr_6.3/solr-6.3.0-setup/contrib/ltr/example
Warning: /techproducts-features.json", this makes an empty POST.
{
"responseHeader":{
"status":500,
"QTime":3},
"error":{
"msg":"Bad Request",
"trace":"Bad Request (400) - Empty request body!\n\tat
org.apache.solr.rest.RestManager$ManagedEndpoint.parseJsonFromRequestBody(RestManager.java:420)\n\tat
org.apache.solr.rest.RestManager$ManagedEndpoint.put(RestManager.java:340)\n\tat
org.restlet.resource.ServerResource.doHandle(ServerResource.java:447)\n\tat
org.restlet.resource.ServerResource.doConditionalHandle(ServerResource.java:359)\n\tat
org.restlet.resource.ServerResource.handle(ServerResource.java:1044)\n\tat
org.restlet.resource.Finder.handle(Finder.java:236)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:140)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)\n\tat
org.restlet.engine.application.ApplicationHelper.handle(ApplicationHelper.java:75)\n\tat
org.restlet.Application.handle(Application.java:385)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.routing.Router.doHandle(Router.java:422)\n\tat
org.restlet.routing.Router.handle(Router.java:639)\n\tat
org.restlet.routing.Filter.doHandle(Filter.java:150)\n\tat
org.restlet.routing.Filter.handle(Filter.java:197)\n\tat
org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:202)\n\tat
org.restlet.Component.handle(Component.java:408)\n\tat
org.restlet.Server.handle(Server.java:507)\n\tat
org.restlet.engine.connector.ServerHelper.handle(ServerHelper.java:63)\n\tat
org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:143)\n\tat
org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:1117)\n\tat
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:199)\n\tat
org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:74)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:312)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
[jira] [Updated] (LUCENE-7401) BKDWriter should ensure all dimensions are indexed
[ https://issues.apache.org/jira/browse/LUCENE-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-7401: - Attachment: LUCENE-7401.patch bq. That's a good example! In that case, with our current splitting, running a range filter for "small population" will be costly. Though, without other filters (by lat/lon) it will likely be costly anyway since town population is probably Zipf's law like? I.e., most areas will still have many more small population towns than big ones. Right, a filter for "small population" is costly, but I don't think we can do much about it since it is due to the fact it would match lots of documents. The problem that would like to address here is the opposite: filtering for "large population", for instance: "Find all cities in America that have more than 10K inhabitants". This would be a selective filter, so hopefully something that we can execute efficiently. However with the current way the splitting works, the population dimension might never be indexed (because BKD would always decide to index the lat or lon instead, which have larger ranges) and such a query, which is very selective on the population dimension, would likely have to visit all documents that match "America" to find matches, which is disappointing. Here is a patch that implements what I had in mind when opening this ticket. It ensures that every dimension gets split no less than 2x less than the dimension that had the most splits. So back to our 3 dimensions example with lat, lon and population, let's assume we have 1M docs, it would mean we need to split 10 times. In such a scenario, we would likely split 4 times on lat, 4 times on lon and 2 times on the population dimension. I think it is a better trade-off since it has a better worst case for selective queries. For instance the fact that today the geo dimensions would get 10 splits means that a selective geo query would have to visit 1/1024th of the index, but a selective query on population would have to perform a linear scan. With this patch a selective geo query would have to visit 1/256th of the index (8 splits), which is slower, however a selective query on the population dimension would only have to visit 1/4th of the index (2 splits). > BKDWriter should ensure all dimensions are indexed > -- > > Key: LUCENE-7401 > URL: https://issues.apache.org/jira/browse/LUCENE-7401 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7401.patch > > > The current heuristic is to use the dimension that has the largest span, so > if dimensions have a different distribution of values, we could theoretically > (but maybe in practice too?) end up with one dimension that is not indexed at > all and queries that are mostly selective on this dimension would need to > scan lots of blocks. -- 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
How to get SOLR document metadata in UIMA using SOLR6.3
Hi All, I am working on SOLR and UIMA development assignment. where I need to pass some of the SOLR document metadata to UIMA chain. Is there any concrete example on how to do SO. For example if I have pass "title" information to the UIMA update processor then how can I do it. I am searching for a concrete documentation. As far as SOLR is concerned I can send document indexed field in below fasion. false text title how to get value of "title" from UIMA. Do I have do create some input features. Please help. Regards Soumitra -- View this message in context: http://lucene.472066.n3.nabble.com/How-to-get-SOLR-document-metadata-in-UIMA-using-SOLR6-3-tp4311032.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 569 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/569/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102) at sun.reflect.GeneratedConstructorAccessor161.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:704) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:766) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1005) at org.apache.solr.core.SolrCore.(SolrCore.java:870) at org.apache.solr.core.SolrCore.(SolrCore.java:774) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:842) at org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102) at sun.reflect.GeneratedConstructorAccessor161.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:704) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:766) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1005) at org.apache.solr.core.SolrCore.(SolrCore.java:870) at org.apache.solr.core.SolrCore.(SolrCore.java:774) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:842) at org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([399238EDF9E75943]: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.teardownTestCases(SolrTestCaseJ4.java:266) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) 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:45) at
