[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13771 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13771/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.cloud.HttpPartitionTest.test
Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms!
ClusterState: { collection1:{ replicationFactor:1, shards:{
shard1:{ range:8000-, state:active,
replicas:{core_node2:{ core:collection1,
base_url:http://127.0.0.1:45609/_o/ne;,
node_name:127.0.0.1:45609__o%2Fne, state:active,
leader:true}}}, shard2:{ range:0-7fff,
state:active, replicas:{ core_node1:{
core:collection1, base_url:http://127.0.0.1:47666/_o/ne;,
node_name:127.0.0.1:47666__o%2Fne, state:active,
leader:true}, core_node3:{
core:collection1, base_url:http://127.0.0.1:56978/_o/ne;,
node_name:127.0.0.1:56978__o%2Fne,
state:active, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false,
autoCreated:true}, control_collection:{ replicationFactor:1,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{core_node1:{
core:collection1, base_url:http://127.0.0.1:33024/_o/ne;,
node_name:127.0.0.1:33024__o%2Fne, state:active,
leader:true, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false,
autoCreated:true}, c8n_1x2:{ replicationFactor:2,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{ core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:56978/_o/ne;,
node_name:127.0.0.1:56978__o%2Fne, state:active,
leader:true}, core_node2:{ state:down,
base_url:http://127.0.0.1:45609/_o/ne;,
core:c8n_1x2_shard1_replica1,
node_name:127.0.0.1:45609__o%2Fne, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false}}
Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2
come up within 3 ms! ClusterState: {
collection1:{
replicationFactor:1,
shards:{
shard1:{
range:8000-,
state:active,
replicas:{core_node2:{
core:collection1,
base_url:http://127.0.0.1:45609/_o/ne;,
node_name:127.0.0.1:45609__o%2Fne,
state:active,
leader:true}}},
shard2:{
range:0-7fff,
state:active,
replicas:{
core_node1:{
core:collection1,
base_url:http://127.0.0.1:47666/_o/ne;,
node_name:127.0.0.1:47666__o%2Fne,
state:active,
leader:true},
core_node3:{
core:collection1,
base_url:http://127.0.0.1:56978/_o/ne;,
node_name:127.0.0.1:56978__o%2Fne,
state:active,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
control_collection:{
replicationFactor:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{core_node1:{
core:collection1,
base_url:http://127.0.0.1:33024/_o/ne;,
node_name:127.0.0.1:33024__o%2Fne,
state:active,
leader:true,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
c8n_1x2:{
replicationFactor:2,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:56978/_o/ne;,
node_name:127.0.0.1:56978__o%2Fne,
state:active,
leader:true},
core_node2:{
state:down,
base_url:http://127.0.0.1:45609/_o/ne;,
core:c8n_1x2_shard1_replica1,
node_name:127.0.0.1:45609__o%2Fne,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false}}
at
__randomizedtesting.SeedInfo.seed([C081CA6011CD6F59:48D5F5BABF3102A1]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1842)
at
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:248)
at
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4992 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4992/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([604478AA990F627C:A8961D3C06064526]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 923 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/923/ 4 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:42293/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:42293/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([422BF5155421CCA:8C76808BFBBE7132]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Commented] (SOLR-7899) Non-reproducible test failures on TestSQLHandler
[
https://issues.apache.org/jira/browse/SOLR-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662734#comment-14662734
]
Joel Bernstein commented on SOLR-7899:
--
One of the NPE seems to occur at the same time as an index recovery error:
[junit4] 2 2720006 ERROR (qtp1663135144-18198) [n:127.0.0.1:53077_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.s.SolrDispatchFilter
null:java.lang.NullPointerException
[junit4] 2at
org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:107)
[junit4] 2at
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
[junit4] 2at
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:722)
[junit4] 2at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
[junit4] 2at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:226)
[junit4] 2at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[junit4] 2at
org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
[junit4] 2at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
[junit4] 2at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
[junit4] 2at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
[junit4] 2at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
[junit4] 2at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[junit4] 2at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
[junit4] 2at
org.eclipse.jetty.server.Server.handle(Server.java:499)
[junit4] 2at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
[junit4] 2at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
[junit4] 2at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
[junit4] 2at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
[junit4] 2at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
[junit4] 2at java.lang.Thread.run(Thread.java:745)
[junit4] 2
[junit4] 2 2720006 INFO (qtp1144546167-18142) [n:127.0.0.1:53033_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.S.Request
[collection1] webapp= path=/replication
params={generation=8qt=/replicationfile=_3_Asserting_0.dvmchecksum=truewt=filestreamcommand=filecontent}
status=0 QTime=6
[junit4] 2 2720021 WARN (RecoveryThread-collection1) [n:127.0.0.1:53077_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.h.IndexFetcher Could
not retrieve checksum from file.
[junit4] 2 java.lang.ArrayIndexOutOfBoundsException: -16
[junit4] 2at
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:73)
[junit4] 2at
org.apache.lucene.store.DataInput.readInt(DataInput.java:101)
[junit4] 2at
org.apache.lucene.store.MockIndexInputWrapper.readInt(MockIndexInputWrapper.java:157)
[junit4] 2at
org.apache.lucene.codecs.CodecUtil.validateFooter(CodecUtil.java:414)
[junit4] 2at
org.apache.lucene.codecs.CodecUtil.retrieveChecksum(CodecUtil.java:401)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.compareFile(IndexFetcher.java:873)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.downloadIndexFiles(IndexFetcher.java:836)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:433)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:262)
[junit4] 2at
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:381)
[junit4] 2at
[jira] [Comment Edited] (SOLR-7899) Non-reproducible test failures on TestSQLHandler
[
https://issues.apache.org/jira/browse/SOLR-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662734#comment-14662734
]
Joel Bernstein edited comment on SOLR-7899 at 8/8/15 1:15 AM:
--
One of the NPE's seems to occur at the same time as an index recovery error:
[junit4] 2 2720006 ERROR (qtp1663135144-18198) [n:127.0.0.1:53077_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.s.SolrDispatchFilter
null:java.lang.NullPointerException
[junit4] 2at
org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:107)
[junit4] 2at
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
[junit4] 2at
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:722)
[junit4] 2at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
[junit4] 2at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:226)
[junit4] 2at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[junit4] 2at
org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
[junit4] 2at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
[junit4] 2at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
[junit4] 2at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
[junit4] 2at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
[junit4] 2at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
[junit4] 2at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[junit4] 2at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
[junit4] 2at
org.eclipse.jetty.server.Server.handle(Server.java:499)
[junit4] 2at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
[junit4] 2at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
[junit4] 2at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
[junit4] 2at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
[junit4] 2at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
[junit4] 2at java.lang.Thread.run(Thread.java:745)
[junit4] 2
[junit4] 2 2720006 INFO (qtp1144546167-18142) [n:127.0.0.1:53033_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.S.Request
[collection1] webapp= path=/replication
params={generation=8qt=/replicationfile=_3_Asserting_0.dvmchecksum=truewt=filestreamcommand=filecontent}
status=0 QTime=6
[junit4] 2 2720021 WARN (RecoveryThread-collection1) [n:127.0.0.1:53077_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.h.IndexFetcher Could
not retrieve checksum from file.
[junit4] 2 java.lang.ArrayIndexOutOfBoundsException: -16
[junit4] 2at
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:73)
[junit4] 2at
org.apache.lucene.store.DataInput.readInt(DataInput.java:101)
[junit4] 2at
org.apache.lucene.store.MockIndexInputWrapper.readInt(MockIndexInputWrapper.java:157)
[junit4] 2at
org.apache.lucene.codecs.CodecUtil.validateFooter(CodecUtil.java:414)
[junit4] 2at
org.apache.lucene.codecs.CodecUtil.retrieveChecksum(CodecUtil.java:401)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.compareFile(IndexFetcher.java:873)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.downloadIndexFiles(IndexFetcher.java:836)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:433)
[junit4] 2at
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:262)
[junit4] 2at
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:381)
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2597 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2597/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: Could not find a healthy node to handle the request. Stack Trace: org.apache.solr.common.SolrException: Could not find a healthy node to handle the request. at __randomizedtesting.SeedInfo.seed([EEBC3C717A98AF9B:66E803ABD464C263]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1070) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1503) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_80) - Build # 13576 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13576/ Java: 32bit/jdk1.7.0_80 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([60E577134DA382A1:A8371285D2AAA5FB]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Commented] (SOLR-7899) Non-reproducible test failures on TestSQLHandler
[
https://issues.apache.org/jira/browse/SOLR-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662753#comment-14662753
]
Joel Bernstein commented on SOLR-7899:
--
Another failure with a recovery error happening near by:
55 WARN (RecoveryThread-collection1) [n:127.0.0.1:55811_ c:collection1
s:shard2 r:core_node3 x:collection1] o.a.s.h.IndexFetcher Could not retrieve
checksum from file.
[junit4] 2 java.lang.ArrayIndexOutOfBoundsException
[junit4] 2 208855 WARN (RecoveryThread-collection1) [n:127.0.0.1:55811_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.h.IndexFetcher File
_3.fdx did not match. expected length is 84 and actual length is 0
[junit4] 2 208858 INFO (qtp1682481233-1058) [n:127.0.0.1:55795_
c:control_collection s:shard1 r:core_node1 x:collection1]
o.a.s.s.SolrIndexSearcher Opening Searcher@3e480f7e[collection1] main
[junit4] 2 208859 INFO (qtp1682481233-1058) [n:127.0.0.1:55795_
c:control_collection s:shard1 r:core_node1 x:collection1] o.a.s.u.UpdateHandler
end_commit_flush
[junit4] 2 208859 INFO
(searcherExecutor-527-thread-1-processing-n:127.0.0.1:55795_ x:collection1
s:shard1 c:control_collection r:core_node1) [n:127.0.0.1:55795_
c:control_collection s:shard1 r:core_node1 x:collection1] o.a.s.c.SolrCore
[collection1] Registered new searcher Searcher@3e480f7e[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_3(6.0.0):C8)))}
[junit4] 2 208859 INFO (qtp1682481233-1058) [n:127.0.0.1:55795_
c:control_collection s:shard1 r:core_node1 x:collection1]
o.a.s.u.p.LogUpdateProcessor [collection1] webapp= path=/update
params={waitSearcher=truecommit=truesoftCommit=falsewt=javabinversion=2}
{commit=} 0 21
[junit4] 2 208860 INFO (qtp794519470-1098) [n:127.0.0.1:55803_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.S.Request
[collection1] webapp= path=/replication
params={generation=8qt=/replicationfile=_3.fdxchecksum=truewt=filestreamcommand=filecontent}
status=0 QTime=2
[junit4] 2 208867 INFO (qtp794519470-1097) [n:127.0.0.1:55803_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.S.Request
[collection1] webapp= path=/replication
params={generation=8qt=/replicationfile=_3_BlockTreeOrds_0.tipochecksum=truewt=filestreamcommand=filecontent}
status=0 QTime=0
[junit4] 2 208868 INFO (qtp1780139914-1127) [n:127.0.0.1:55807_
c:collection1 s:shard1 r:core_node2 x:collection1] o.a.s.u.UpdateHandler start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
[junit4] 2 208869 INFO (qtp423014036-1155) [n:127.0.0.1:55811_
c:collection1 s:shard2 r:core_node3 x:collection1]
o.a.s.u.p.DistributedUpdateProcessor Ignoring commit while not ACTIVE - state:
BUFFERING replay:0
[junit4] 2 208870 INFO (qtp423014036-1155) [n:127.0.0.1:55811_
c:collection1 s:shard2 r:core_node3 x:collection1] o.a.s.u.p.LogUpdateProcessor
[collection1] webapp= path=/update
params={update.distrib=FROMLEADERwaitSearcher=trueopenSearcher=truecommit=truesoftCommit=falsedistrib.from=http://127.0.0.1:55807/collection1/commit_end_point=truewt=javabinversion=2expungeDeletes=false}
{commit=} 0 0
[junit4] 2 208870 INFO (qtp794519470-1099) [n:127.0.0.1:55803_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.u.UpdateHandler start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
[junit4] 2 208868 INFO (qtp1388903139-1185) [n:127.0.0.1:55816_
c:collection1 s:shard1 r:core_node4 x:collection1] o.a.s.u.UpdateHandler start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
[junit4] 2 208875 INFO (qtp794519470-1100) [n:127.0.0.1:55803_
c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.S.Request
[collection1] webapp= path=/replication
params={generation=8qt=/replicationfile=_3_LuceneVarGapFixedInterval_0.tivchecksum=truewt=filestreamcommand=filecontent}
status=0 QTime=0
[junit4] 2 208889 INFO (qtp1388903139-1185) [n:127.0.0.1:55816_
c:collection1 s:shard1 r:core_node4 x:collection1] o.a.s.c.SolrCore
SolrDeletionPolicy.onCommit: commits: num=2
[junit4] 2commit{dir=MockDirectoryWrapper(RAMDirectory@4fb8b42
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@43198aee),segFN=segments_7,generation=7}
[junit4] 2commit{dir=MockDirectoryWrapper(RAMDirectory@4fb8b42
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@43198aee),segFN=segments_8,generation=8}
[junit4] 2 208889 INFO (qtp1388903139-1185) [n:127.0.0.1:55816_
c:collection1 s:shard1 r:core_node4 x:collection1] o.a.s.c.SolrCore newest
commit generation = 8
[junit4] 2 208891 INFO (qtp1388903139-1185) [n:127.0.0.1:55816_
c:collection1 s:shard1 r:core_node4
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2548 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2548/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([1CE0BEE17C36099C:D432DB77E33F2EC6]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5121 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5121/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([81157B92B2FA81CA:684FC0AA2C631162]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765) at org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime10/int/lstresult name=response numFound=0 start=0/result /response request
[jira] [Updated] (SOLR-7869) Overseer does not handle BadVersionException correctly
[
https://issues.apache.org/jira/browse/SOLR-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-7869:
Fix Version/s: (was: 5.3)
5.4
Overseer does not handle BadVersionException correctly
--
Key: SOLR-7869
URL: https://issues.apache.org/jira/browse/SOLR-7869
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.2.1
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Labels: difficulty-medium, impact-low
Fix For: Trunk, 5.4
Attachments: SOLR-7869.patch
If the /clusterstate.json is modified externally then the Overseer can go
into an infinite loop upon a BadVersionException alternately trying to
execute main queue and then the work queue:
{code}
ERROR - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; Exception in Overseer
work queue loop
org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode =
BadVersion for /clusterstate.json
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:115)
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1270)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:362)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:359)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:61)
at
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:359)
at
org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:180)
at
org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:67)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:286)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:168)
at java.lang.Thread.run(Thread.java:745)
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; processMessage:
queueSize: 1, message = {
operation:state,
state:down,
base_url:http://127.0.1.1:7574/solr;,
core:test_shard1_replica1,
roles:null,
node_name:127.0.1.1:7574_solr,
shard:null,
collection:test,
core_node_name:core_node1} current state version: 9
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.overseer.ReplicaMutator; Update state numShards=null
message={
operation:state,
state:down,
base_url:http://127.0.1.1:7574/solr;,
core:test_shard1_replica1,
roles:null,
node_name:127.0.1.1:7574_solr,
shard:null,
collection:test,
core_node_name:core_node1}
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.overseer.ReplicaMutator; shard=shard1 is already
registered
ERROR - 2015-08-04 18:49:56.225; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; Exception in Overseer
main queue loop
org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode =
BadVersion for /clusterstate.json
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:115)
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1270)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:362)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:359)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:61)
at
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:359)
at
org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:180)
at
org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:67)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:286)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:213)
at java.lang.Thread.run(Thread.java:745)
INFO - 2015-08-04 18:49:56.225; [ ]
org.apache.solr.common.cloud.ZkStateReader; Updating data for gettingstarted
to ver 8
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4993 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4993/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([AF31611616FB362D:67E3048089F21177]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
[jira] [Updated] (SOLR-7869) Overseer does not handle BadVersionException correctly
[
https://issues.apache.org/jira/browse/SOLR-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-7869:
Attachment: SOLR-7869.patch
Test + fix. I tried to reproduce this in the OverseerTest but it was proving to
be too difficult. The randomized test I had would maybe reproduce once in 5
times so I went back to the test Scott had written and augmented it.
# I wonder if it is better to assert that given cluster state version is
greater than ZkStateWriter's internal cluster state instead of blindly using
given cluster state when version is not equal.
# I also wonder if a better fix is to re-create ZkStateWriter object entirely
if refreshClusterState is true in the Overseer? The reason is what if a user
modifies a collection's state.json directly but doesn't modify the
/clusterstate.json. In that case, our current fix won't work.
Overseer does not handle BadVersionException correctly
--
Key: SOLR-7869
URL: https://issues.apache.org/jira/browse/SOLR-7869
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.2.1
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Labels: difficulty-medium, impact-low
Fix For: Trunk, 5.4
Attachments: SOLR-7869.patch, SOLR-7869.patch
If the /clusterstate.json is modified externally then the Overseer can go
into an infinite loop upon a BadVersionException alternately trying to
execute main queue and then the work queue:
{code}
ERROR - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; Exception in Overseer
work queue loop
org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode =
BadVersion for /clusterstate.json
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:115)
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1270)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:362)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:359)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:61)
at
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:359)
at
org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:180)
at
org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:67)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:286)
at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:168)
at java.lang.Thread.run(Thread.java:745)
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; processMessage:
queueSize: 1, message = {
operation:state,
state:down,
base_url:http://127.0.1.1:7574/solr;,
core:test_shard1_replica1,
roles:null,
node_name:127.0.1.1:7574_solr,
shard:null,
collection:test,
core_node_name:core_node1} current state version: 9
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.overseer.ReplicaMutator; Update state numShards=null
message={
operation:state,
state:down,
base_url:http://127.0.1.1:7574/solr;,
core:test_shard1_replica1,
roles:null,
node_name:127.0.1.1:7574_solr,
shard:null,
collection:test,
core_node_name:core_node1}
INFO - 2015-08-04 18:49:56.224; [ ]
org.apache.solr.cloud.overseer.ReplicaMutator; shard=shard1 is already
registered
ERROR - 2015-08-04 18:49:56.225; [ ]
org.apache.solr.cloud.Overseer$ClusterStateUpdater; Exception in Overseer
main queue loop
org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode =
BadVersion for /clusterstate.json
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:115)
at
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1270)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:362)
at
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:359)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:61)
at
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:359)
at
org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:180)
at
org.apache.solr.cloud.overseer.ZkStateWriter.enqueueUpdate(ZkStateWriter.java:67)
at
[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 293 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/293/ No tests ran. Build Log: [...truncated 53340 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist [copy] Copying 461 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 245 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.7 JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 [smoker] Java 1.8 JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.01 sec (11.9 MB/sec) [smoker] check changes HTML... [smoker] download lucene-5.4.0-src.tgz... [smoker] 28.5 MB in 0.04 sec (770.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.4.0.tgz... [smoker] 65.8 MB in 0.08 sec (775.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.4.0.zip... [smoker] 76.1 MB in 0.10 sec (754.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-5.4.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 6059 hits for query lucene [smoker] checkindex with 1.7... [smoker] test demo with 1.8... [smoker] got 6059 hits for query lucene [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.4.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 6059 hits for query lucene [smoker] checkindex with 1.7... [smoker] test demo with 1.8... [smoker] got 6059 hits for query lucene [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.4.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run ant validate [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.7... [smoker] got 213 hits for query lucene [smoker] checkindex with 1.7... [smoker] generate javadocs w/ Java 7... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 213 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.1 MB in 0.01 sec (21.5 MB/sec) [smoker] check changes HTML... [smoker] download solr-5.4.0-src.tgz... [smoker] 36.9 MB in 0.38 sec (98.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.4.0.tgz... [smoker] 128.8 MB in 1.48 sec (87.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.4.0.zip... [smoker] 136.4 MB in 1.58 sec (86.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-5.4.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-5.4.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.4.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-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.4.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 7 ... [smoker] test solr example w/ Java 7... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.4.0-java7/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] starting Solr on port 8983 from
[jira] [Updated] (SOLR-7836) Possible deadlock when closing refcounted index writers.
[
https://issues.apache.org/jira/browse/SOLR-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-7836:
-
Attachment: SOLR-7836.patch
This might do it. I'm running 1,000 iterations (or until morning, whichever
comes first) but it's gone through 150 or so already which was usually more
than enough to trigger the new deadlock I found so I'm hopeful. Actually, I
think this really the old deadlock, the first fix wasn't very good.
There are two things I'd appreciate any opinions on:
1 this patch moves the UpdateLog.add() command out of the ref counted
IndexWriter in DirectUpdateHandler2.addDoc0() in multiple places (refactored to
methods). But UpdateLog.add gets a new IndexWriter itself which is where the
deadlock appears to be as it's fighting with CoreContainer.reload() which also
calls DefaultSolrCoreState.newIndexWriter.
2 There are two nocommits, but they are to make it easy for someone to see the
other bit that other eyes would be most welcome on, I moved
if (ulog != null) ulog.add(cmd, true);
out of a synchronized block. This fits the pattern in other places in that code
too, so I'm not too worried, but wanted to draw attention to it if anyone wants
to look. Actually, there are a lot of operations on ulog.something that are
synchronized on solrCoreState.getUpdateLock(), and a bunch that aren't. What's
up there? The change marked by //nocommit matches the (non-synchronized) usages
in addDoc0() though.
Anyway, the problem was in DirectUpdateHandler2.addDoc0(). The ulog.add command
line being inside a ref-counted IndexWriter when adding documents (addAndDelete
case). ulog.add eventually tries to get a new Searcher which can be deadlocked
with another thread called from SolrCore.reload since the reload wants a new
IndexWriter.
I haven't run precommit or the full test suite yet, I want to make sure the
iterations I'm doing tonight work.
This looks more intrusive than it is. I refactored some methods out of
DirectUpdateHandler2.addDoc0() in order to make this pattern more visible. The
original code concealed the fact that the ref counted index writer surrounded
all the code, including the ulog.add.
this is the pattern for all the refactored methods:
RefCountedIndexWriter iw = solrCoreState.getIndexWriter(core);
try {
IndexWriter writer = iw.get();
do the right thing
} finally {
iw.decref();
}
if (ulog != null) ulog.add(cmd, true);
I think this is a better approach than the original fix which passed the index
writer down to the addAndDelete method. we'd have had to pass the IndexWriter
on to the ulog.add command or something which would have been a pain (even if
it was possible).
New test case is in this patch. Note that it's a race condition to get this to
fail, so it needs to be run a lot. And using tests.iters apparently triggers
the timeouts so
Possible deadlock when closing refcounted index writers.
Key: SOLR-7836
URL: https://issues.apache.org/jira/browse/SOLR-7836
Project: Solr
Issue Type: Bug
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-7836.patch, SOLR-7836.patch
Preliminary patch for what looks like a possible race condition between
writerFree and pauseWriter in DefaultSorlCoreState.
Looking for comments and/or why I'm completely missing the boat.
--
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-7836) Possible deadlock when closing refcounted index writers.
[
https://issues.apache.org/jira/browse/SOLR-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662814#comment-14662814
]
Erick Erickson edited comment on SOLR-7836 at 8/8/15 5:31 AM:
--
This might do it. I'm running 1,000 iterations (or until morning, whichever
comes first) but it's gone through 150 or so already which was usually more
than enough to trigger the new deadlock I found so I'm hopeful. Actually, I
think this really the old deadlock, the first fix wasn't very good.
There are two things I'd appreciate any opinions on:
1 this patch moves the UpdateLog.add() command out of the ref counted
IndexWriter in DirectUpdateHandler2.addDoc0() in multiple places (refactored to
methods). But UpdateLog.add gets a new IndexWriter itself which is where the
deadlock appears to be as it's fighting with CoreContainer.reload() which also
calls DefaultSolrCoreState.newIndexWriter.
2 There are two nocommits, but they are to make it easy for someone to see the
other bit that other eyes would be most welcome on, I moved
if (ulog != null) ulog.add(cmd, true);
out of a synchronized block. This fits the pattern in other places in that code
too, so I'm not too worried, but wanted to draw attention to it if anyone wants
to look. Actually, there are a lot of operations on ulog.something that are
synchronized on solrCoreState.getUpdateLock(), and a bunch that aren't. What's
up there? The change marked by //nocommit matches the (non-synchronized) usages
in addDoc0() though.
Anyway, the problem was in DirectUpdateHandler2.addDoc0(). The ulog.add command
line being inside a ref-counted IndexWriter when adding documents (addAndDelete
case). ulog.add eventually tries to get a new Searcher which can be deadlocked
with another thread called from SolrCore.reload since the reload wants a new
IndexWriter.
I haven't run precommit or the full test suite yet, I want to make sure the
iterations I'm doing tonight work.
This looks more intrusive than it is. I refactored some methods out of
DirectUpdateHandler2.addDoc0() in order to make this pattern more visible. The
original code concealed the fact that the ref counted index writer surrounded
all the code, including the ulog.add.
this is the pattern for all the refactored methods:
{code}
RefCountedIndexWriter iw = solrCoreState.getIndexWriter(core);
try {
IndexWriter writer = iw.get();
do the right thing
} finally {
iw.decref();
}
if (ulog != null) ulog.add(cmd, true);
{code}
I think this is a better approach than the original fix which passed the index
writer down to the addAndDelete method. we'd have had to pass the IndexWriter
on to the ulog.add command or something which would have been a pain (even if
it was possible).
New test case is in this patch. Note that it's a race condition to get this to
fail, so it needs to be run a lot. And using tests.iters apparently triggers
the timeouts so
was (Author: erickerickson):
This might do it. I'm running 1,000 iterations (or until morning, whichever
comes first) but it's gone through 150 or so already which was usually more
than enough to trigger the new deadlock I found so I'm hopeful. Actually, I
think this really the old deadlock, the first fix wasn't very good.
There are two things I'd appreciate any opinions on:
1 this patch moves the UpdateLog.add() command out of the ref counted
IndexWriter in DirectUpdateHandler2.addDoc0() in multiple places (refactored to
methods). But UpdateLog.add gets a new IndexWriter itself which is where the
deadlock appears to be as it's fighting with CoreContainer.reload() which also
calls DefaultSolrCoreState.newIndexWriter.
2 There are two nocommits, but they are to make it easy for someone to see the
other bit that other eyes would be most welcome on, I moved
if (ulog != null) ulog.add(cmd, true);
out of a synchronized block. This fits the pattern in other places in that code
too, so I'm not too worried, but wanted to draw attention to it if anyone wants
to look. Actually, there are a lot of operations on ulog.something that are
synchronized on solrCoreState.getUpdateLock(), and a bunch that aren't. What's
up there? The change marked by //nocommit matches the (non-synchronized) usages
in addDoc0() though.
Anyway, the problem was in DirectUpdateHandler2.addDoc0(). The ulog.add command
line being inside a ref-counted IndexWriter when adding documents (addAndDelete
case). ulog.add eventually tries to get a new Searcher which can be deadlocked
with another thread called from SolrCore.reload since the reload wants a new
IndexWriter.
I haven't run precommit or the full test suite yet, I want to make sure the
iterations I'm doing tonight work.
This looks more intrusive than it is. I refactored some methods out of
DirectUpdateHandler2.addDoc0() in order to make this pattern more visible. The
original code concealed the fact
[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13577 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13577/ Java: 32bit/jdk1.8.0_60-ea-b24 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([7E0BFF7264FC2921:B6D99AE4FBF50E7B]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
[jira] [Comment Edited] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662292#comment-14662292
]
Supriya Bommareddy edited comment on SOLR-4455 at 8/7/15 7:20 PM:
--
I tried the workaround with the following changes in my solrconfig.xml and its
not working. I have solr-5.2.1 installed.
NOTE: I am not sending the timestamp field in the document and I am updating
the document via the admin console UI.
{code}
requestHandler name=/update class=solr.UpdateRequestHandler
!-- See below for information on defining
updateRequestProcessorChains that can be used by name
on each Update Request
--
lst name=defaults
str name=update.chaintimestamp/str
/lst
/requestHandler
updateRequestProcessorChain name=timestamp default=true
processor class=solr.TimestampUpdateProcessorFactory
str name=fieldNametimestamp/str
/processor
processor class=solr.DistributedUpdateProcessorFactory/
processor class=solr.LogUpdateProcessorFactory /
processor class=solr.RunUpdateProcessorFactory /
/updateRequestProcessorChain
{code}
*
schema.xml has the below entry
{code}
field name=timestamp type=date indexed=true stored=true
multiValued=false/
fieldType name=date class=solr.TrieDateField precisionStep=0
positionIncrementGap=0/
{code}
was (Author: supreddy):
I tried the workaround with the following changes in my solrconfig.xml and its
not working. I have solr-5.2.1 installed
{code}
requestHandler name=/update class=solr.UpdateRequestHandler
!-- See below for information on defining
updateRequestProcessorChains that can be used by name
on each Update Request
--
lst name=defaults
str name=update.chaintimestamp/str
/lst
/requestHandler
updateRequestProcessorChain name=timestamp default=true
processor class=solr.TimestampUpdateProcessorFactory
str name=fieldNametimestamp/str
/processor
processor class=solr.DistributedUpdateProcessorFactory/
processor class=solr.LogUpdateProcessorFactory /
processor class=solr.RunUpdateProcessorFactory /
/updateRequestProcessorChain
{code}
*
schema.xml has the below entry
{code}
field name=timestamp type=date indexed=true stored=true
multiValued=false/
fieldType name=date class=solr.TrieDateField precisionStep=0
positionIncrementGap=0/
{code}
Stored value of NOW differs between replicas
--
Key: SOLR-4455
URL: https://issues.apache.org/jira/browse/SOLR-4455
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.1
Reporter: Colin Bartolome
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-4455.patch
I have a field in {{schema.xml}} defined like this:
{code:xml}
field name=timestamp type=date indexed=true stored=true
default=NOW /
{code}
When I perform a query that's load-balanced across the servers in my cloud,
the value stored in that field differs slightly between each replica for the
same returned document.
I haven't seen this field differ by more than a tenth of a second and I'm not
running queries against it, but I can picture a situation where somebody has
one replica returning 23:59:59.990 and another returning 00:00:00.010 and a
query starts behaving oddly.
It seems like the leader should evaluate what NOW means and the replicas
should copy that value.
{panel:title=Possible Workaround}
A possible workaround for this issue is to use the
TimestampUpdateProcessorFactory in your update processor chain prior to the
DistributedUpdateProcessor instead of relying on the using NOW as a default
value for date fields.
This will cause the timestamp field of each document to be filled in with a
value before the documents are forwarded to any shards (or written to the
transaction log)
https://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/update/processor/TimestampUpdateProcessorFactory.html
{panel}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 5.3 release
Ok. Many thanks!
I was not sure, I think I removed the workspaces using the Gui after disabling
them. I just wanted to be sure we not run out of disk space.
Uwe
Am 7. August 2015 21:02:39 MESZ, schrieb Steve Rowe sar...@gmail.com:
On Aug 7, 2015, at 2:50 PM, Steve Rowe sar...@gmail.com wrote:
On Aug 5, 2015, at 3:10 PM, Uwe Schindler u...@thetaphi.de wrote:
Steve: For ASF Jenkins, it would be ideal to rename the preexisting
5.2 jobs and simply change the branch in the subversion settings.
Before doing that, be sure to delete the old workspace using the GUI (I
am not sure if I did that already...)!!! This is important, because
Jenkins does not delete the workspace automatically on rename/job
delete, so it consumes large amounts of disk space, which is very
limited on the lucene machine.
I checked, and there should be enough disk space to hold the new 5.3
jobs - judging by the 5.x jobs they’re copied from, they should take up
~17GB of the available ~39GB:
——
sarowe@lucene1-us-west:/home/jenkins/jenkins-slave/workspace$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 82437808 38832960 39394212 50% /x1
——
——
sarowe@lucene1-us-west:/home/jenkins/jenkins-slave/workspace$ du -s
*5.x 2/dev/null | perl -pae '$sum += $F[0]; END { print Total:
$sum\n }'
973404 Lucene-Artifacts-5.x
5933652 Lucene-Solr-Clover-5.x
1621872 Lucene-Solr-Maven-5.x
2933128 Lucene-Solr-NightlyTests-5.x
3562984 Lucene-Solr-SmokeRelease-5.x
1618564 Solr-Artifacts-5.x
Total: 16643604
——
Oops, the *5.x glob missed the Lucene-Solr-Tests-5.x-Java7 job’s
workspace - here’s the correct version:
——
sarowe@lucene1-us-west:/home/jenkins/jenkins-slave/workspace$ du -s
*5.x* 2/dev/null | perl -pae '$sum += $F[0]; END { print Total:
$sum\n }'
973404 Lucene-Artifacts-5.x
5933652Lucene-Solr-Clover-5.x
1621872Lucene-Solr-Maven-5.x
2933128Lucene-Solr-NightlyTests-5.x
3562984Lucene-Solr-SmokeRelease-5.x
1029620Lucene-Solr-Tests-5.x-Java7
1618564Solr-Artifacts-5.x
Total: 17673224
——
So it’s still ok: ~18GB of the available ~40GB.
Steve
www.lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2596 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2596/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestRebalanceLeaders.test Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:59606, http://127.0.0.1:59630, http://127.0.0.1:59611, http://127.0.0.1:59599, http://127.0.0.1:59636] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:59606, http://127.0.0.1:59630, http://127.0.0.1:59611, http://127.0.0.1:59599, http://127.0.0.1:59636] at __randomizedtesting.SeedInfo.seed([1C516F9BB1259E51:940550411FD9F3A9]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1085) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.TestRebalanceLeaders.issueCommands(TestRebalanceLeaders.java:280) at org.apache.solr.cloud.TestRebalanceLeaders.rebalanceLeaderTest(TestRebalanceLeaders.java:107) at org.apache.solr.cloud.TestRebalanceLeaders.test(TestRebalanceLeaders.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13765 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13765/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.security.PKIAuthenticationIntegrationTest.testPkiAuth Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([EDB9A51ECADF3794:DD073C4F2A69B035]: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.security.PKIAuthenticationIntegrationTest.testPkiAuth(PKIAuthenticationIntegrationTest.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at
[jira] [Commented] (LUCENE-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661820#comment-14661820 ] Jan Eerdekens commented on LUCENE-6725: --- The tests for Lucene 4.10.4 for the 3 JVM versions don't seem to cause JVM crashes. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- 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-7868) CdcrReplicationDistributedZkTest can take way to long to run.
[ https://issues.apache.org/jira/browse/SOLR-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-7868: -- Fix Version/s: (was: 5.4) CdcrReplicationDistributedZkTest can take way to long to run. - Key: SOLR-7868 URL: https://issues.apache.org/jira/browse/SOLR-7868 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk Two test runs in a row and this test has run for minutes. -- 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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661849#comment-14661849
]
Jan Høydahl commented on SOLR-7888:
---
Thanks for the contribution, looks promising. Just browsed the code, have not
tested or looked thoroughly. What analysis is applied to the new contextfield?
Do we need it to be configurable?
I can probably help next week if I find some time...
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Attachments: SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated SOLR-7760:
--
Fix Version/s: (was: 5.3)
5.4
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: Trunk, 5.4
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13766 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13766/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([DBCD338582C23CBE:7C898B21EF792F07]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Resolved] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-7877.
---
Resolution: Fixed
Change committed to trunk, branch_5x and lucene_solr_5_3. Please see SOLR-7886
re: {{TestMiniSolrCloudCluster}} refactoring discussion and efforts.
TestAuthenticationFramework.testBasics to preserve/restore the original
request(Username|Password)
--
Key: SOLR-7877
URL: https://issues.apache.org/jira/browse/SOLR-7877
Project: Solr
Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
Fix For: 5.3, Trunk, 5.4
{code}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
Error Message:
Error from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html head meta
http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem
accessing /solr/admin/collections. Reason: preUnauthorized
request/pre/p hr /ismallPowered by Jetty:///small/i /body
/html
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html
head
meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title
/head
body
h2HTTP ERROR: 401/h2
pProblem accessing /solr/admin/collections. Reason:
preUnauthorized request/pre/p
hr /ismallPowered by Jetty:///small/i
/body
/html
at
__randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
at
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
{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
[jira] [Commented] (SOLR-7849) Secure Inter-node communication in a standard mechanism
[
https://issues.apache.org/jira/browse/SOLR-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661817#comment-14661817
]
ASF subversion and git services commented on SOLR-7849:
---
Commit 1694683 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694683 ]
SOLR-7849: avoid re-regisetring pkiAuthentication plugin http interceptor
Secure Inter-node communication in a standard mechanism
Key: SOLR-7849
URL: https://issues.apache.org/jira/browse/SOLR-7849
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.3, Trunk
Attachments: SOLR-7849.patch, SOLR-7849.patch, SOLR-7849.patch,
SOLR-7849.patch
Relying on every Authentication plugin to secure the internode communication
is error prone. Solr can standardize the authentication so that only the
first request that comes from outside the cluster needs to be authenticated
by the authentication plugin
The scheme to protect the communication will be as follows
* Every Solr node creates a an RSA key pair
* The private key is kept private and the public key is made available
through a core admin API
* If authentication is enabled , every outgoing request will carry an extra
header {{ SolrAuth : nodename
encrypt_with_pvt_key(original-user-principal timestamp) }}
* If authentication is enabled {{SolrDispatchFilter}} would look for this
header and see the nodename
** If the public key of the nodename is available in cache , make a request
to the node and fetch the public key
** If the public key has changed (because of a server restart) decryption
fails and the public keyis fetched again
* If the decryption succeeds , the user-name is set to what the header has
encoded
--
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-7868) CdcrReplicationDistributedZkTest can take way to long to run.
[ https://issues.apache.org/jira/browse/SOLR-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-7868: - Assignee: Mark Miller CdcrReplicationDistributedZkTest can take way to long to run. - Key: SOLR-7868 URL: https://issues.apache.org/jira/browse/SOLR-7868 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.4 Two test runs in a row and this test has run for minutes. -- 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-7868) CdcrReplicationDistributedZkTest can take way to long to run.
[ https://issues.apache.org/jira/browse/SOLR-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-7868. --- Resolution: Fixed Fix Version/s: 5.4 Trunk CdcrReplicationDistributedZkTest can take way to long to run. - Key: SOLR-7868 URL: https://issues.apache.org/jira/browse/SOLR-7868 Project: Solr Issue Type: Test Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk, 5.4 Two test runs in a row and this test has run for minutes. -- 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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661834#comment-14661834
]
Michael McCandless commented on SOLR-7888:
--
Hi [~arcadius], I agree we should add this to Solr, but I'm not familiar enough
with this part of Solr to help here ...
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Attachments: SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661853#comment-14661853
]
ASF subversion and git services commented on SOLR-7877:
---
Commit 1694689 from [~cpoerschke] in branch 'dev/branches/lucene_solr_5_3'
[ https://svn.apache.org/r1694689 ]
svn merge for revisions 1694322 and 1694333 from branch_5x (corresponding to
revision 1694314 from trunk)
SOLR-7877: TestAuthenticationFramework.testBasics to preserve/restore the
original request(Username|Password)
TestAuthenticationFramework.testBasics to preserve/restore the original
request(Username|Password)
--
Key: SOLR-7877
URL: https://issues.apache.org/jira/browse/SOLR-7877
Project: Solr
Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
{code}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
Error Message:
Error from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html head meta
http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem
accessing /solr/admin/collections. Reason: preUnauthorized
request/pre/p hr /ismallPowered by Jetty:///small/i /body
/html
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html
head
meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title
/head
body
h2HTTP ERROR: 401/h2
pProblem accessing /solr/admin/collections. Reason:
preUnauthorized request/pre/p
hr /ismallPowered by Jetty:///small/i
/body
/html
at
__randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
at
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
{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
[jira] [Updated] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-7877:
--
Fix Version/s: 5.4
Trunk
5.3
TestAuthenticationFramework.testBasics to preserve/restore the original
request(Username|Password)
--
Key: SOLR-7877
URL: https://issues.apache.org/jira/browse/SOLR-7877
Project: Solr
Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Assignee: Christine Poerschke
Priority: Blocker
Fix For: 5.3, Trunk, 5.4
{code}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
Error Message:
Error from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html head meta
http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title /head body h2HTTP ERROR: 401/h2 pProblem
accessing /solr/admin/collections. Reason: preUnauthorized
request/pre/p hr /ismallPowered by Jetty:///small/i /body
/html
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html. html
head
meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1/
titleError 401 /title
/head
body
h2HTTP ERROR: 401/h2
pProblem accessing /solr/admin/collections. Reason:
preUnauthorized request/pre/p
hr /ismallPowered by Jetty:///small/i
/body
/html
at
__randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
at
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
{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
[jira] [Updated] (SOLR-5756) A utility API to move collections from stateFormat=1 to stateFormat=2
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-5756: Summary: A utility API to move collections from stateFormat=1 to stateFormat=2 (was: A utility API to move collections from internal to external) A utility API to move collections from stateFormat=1 to stateFormat=2 - Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.4 Attachments: SOLR-5756-part2.patch, SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch, SOLR-5756.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-6724) Add support for computing GeoHash neighbors to GeoHashUtils
[ https://issues.apache.org/jira/browse/LUCENE-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662396#comment-14662396 ] Michael McCandless commented on LUCENE-6724: Thanks [~nknize], looks good, I'll commit shortly... Add support for computing GeoHash neighbors to GeoHashUtils --- Key: LUCENE-6724 URL: https://issues.apache.org/jira/browse/LUCENE-6724 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Attachments: LUCENE-6724.patch This simple feature adds the ability to compute the geohash neighbor(s) at a given level, from a provided geohash. Such a utility is beneficial for simple grid faceting/aggregations and geohash based bounding box queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3404 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3404/ 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([7DB87C7DA961ACAF:B56A19EB36688BF5]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_51) - Build # 13575 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13575/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([E4F663FA8FF22C3F:2C24066C10FB0B65]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
[jira] [Commented] (SOLR-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662578#comment-14662578
]
Jan Høydahl commented on SOLR-7888:
---
Let's see if it's a an easy one by copying existing code, if not we can do it
step wise. Should probably handle multi valued input too..
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Attachments: SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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-7899) Non-reproducible test failures on TestSQLHandler
Joel Bernstein created SOLR-7899: Summary: Non-reproducible test failures on TestSQLHandler Key: SOLR-7899 URL: https://issues.apache.org/jira/browse/SOLR-7899 Project: Solr Issue Type: Bug Reporter: Joel Bernstein This ticket is to explore the NPE below that appears about once a week on Jenkins during the TestSQLHandler.doTest testcase. null:java.lang.NullPointerException [junit4] 2at org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:107) [junit4] 2at org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53) [junit4] 2at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:722) [junit4] 2at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462) [junit4] 2at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:226) [junit4] 2at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) [junit4] 2at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) [junit4] 2at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) [junit4] 2at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) [junit4] 2at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) [junit4] 2at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300) [junit4] 2at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) [junit4] 2at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) [junit4] 2at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) [junit4] 2at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) [junit4] 2at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) [junit4] 2at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [junit4] 2at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) [junit4] 2at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [junit4] 2at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) [junit4] 2at org.eclipse.jetty.server.Server.handle(Server.java:499) [junit4] 2at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) [junit4] 2at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) [junit4] 2at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) [junit4] 2at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) [junit4] 2at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) [junit4] 2at java.lang.Thread.run(Thread.java:745) [junit4] 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7795) Fold Interval Faceting into Range Faceting
[
https://issues.apache.org/jira/browse/SOLR-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662573#comment-14662573
]
Tomás Fernández Löbbe commented on SOLR-7795:
-
Thanks [~liahsuan], could you update the pull request?
Skimmed at your commits, I really like how the SolrJ looks like. The one
problem I see, is that in the xml/json response, the key is repeated when
faceting on the same field, like:
{code}...facet.range=pricefacet.range.start=0facet.range.end=50facet.range.gap=10f.price.facet.range.set=[50,*]wt=json
{code}
will generate something like:
{code}
facet_counts:{
facet_queries:{},
facet_fields:{},
facet_dates:{},
facet_ranges:{
price:{
counts:[
0.0,3,
10.0,2,
20.0,0,
30.0,0,
40.0, 0],
gap:10.0,
start:0.0,
end:50.0},
price:{
counts:{
[50,*]:3}}},
facet_intervals:{},
facet_heatmaps:{}}
{code}
Would it be possible to integrate the two price elements? I guess that means
that for intervals we can't use counts for intervals.
Fold Interval Faceting into Range Faceting
--
Key: SOLR-7795
URL: https://issues.apache.org/jira/browse/SOLR-7795
Project: Solr
Issue Type: Task
Reporter: Tomás Fernández Löbbe
Fix For: 5.3, Trunk
Now that range faceting supports a filter and a dv method, and that
interval faceting is supported on fields with {{docValues=false}}, I think we
should make it so that interval faceting is just a different way of
specifying ranges in range faceting, allowing users to indicate specific
ranges.
I propose we use the same syntax for intervals, but under the range
parameter family:
{noformat}
facet.range=price
f.price.facet.range.set=[0,10]
f.price.facet.range.set=(10,100]
{noformat}
The counts for those ranges would come in the response also inside of the
range_facets section. I'm not sure if it's better to include the ranges in
the counts section, or in a different section (intervals?sets?buckets?).
I'm open to suggestions.
{code}
facet_ranges:{
price:{
counts:[
[0,10],3,
(10,100],2]
}
}
{code}
or…
{code}
facet_ranges:{
price:{
intervals:[
[0,10],3,
(10,100],2]
}
}
{code}
We should support people specifying both things on the same field.
Once this is done, interval faceting could be deprecated, as all it's
functionality is now possible through range queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_51) - Build # 13574 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13574/ Java: 32bit/jdk1.8.0_51 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.search.TestSolrQueryParser.testFilter Error Message: Query SortedIntDocSetTopFilter does not implement createWeight Stack Trace: java.lang.UnsupportedOperationException: Query SortedIntDocSetTopFilter does not implement createWeight at __randomizedtesting.SeedInfo.seed([9D4CA0E6FC62A65E:559EC570636B8104]:0) at org.apache.lucene.search.Query.createWeight(Query.java:79) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:117) at org.apache.solr.query.FilterQuery.createWeight(FilterQuery.java:96) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.BooleanWeight.init(BooleanWeight.java:56) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:203) at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:486) at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1259) at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:941) at org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1625) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1501) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:555) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:522) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.util.TestHarness.query(TestHarness.java:320) at org.apache.solr.util.TestHarness.query(TestHarness.java:302) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:831) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:800) at org.apache.solr.search.TestSolrQueryParser.testFilter(TestSolrQueryParser.java:224) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13744 - Still Failing!
Fix committed. Thank you Steve and Adrien for helping me reproduce and fix this. - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: Aug 5 2015 21:32:49 This seed reproduces 100% (3/3 trials) for me on OS X, Java8. [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=A2457E720C1058BA -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 On Aug 5, 2015, at 4:08 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13744/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly Error Message: should have terminated early (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 Stack Trace: java.lang.AssertionError: should have terminated early (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 at __randomizedtesting.SeedInfo.seed([A2457E720C1058BA:83DEC4C0AD2A163D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.java:298) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Commented] (LUCENE-6724) Add support for computing GeoHash neighbors to GeoHashUtils
[ https://issues.apache.org/jira/browse/LUCENE-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662421#comment-14662421 ] ASF subversion and git services commented on LUCENE-6724: - Commit 1694747 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1694747 ] LUCENE-6724: add utility APIs to compute neighboring geohash cells Add support for computing GeoHash neighbors to GeoHashUtils --- Key: LUCENE-6724 URL: https://issues.apache.org/jira/browse/LUCENE-6724 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Attachments: LUCENE-6724.patch This simple feature adds the ability to compute the geohash neighbor(s) at a given level, from a provided geohash. Such a utility is beneficial for simple grid faceting/aggregations and geohash based bounding box queries. -- 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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662504#comment-14662504
]
Arcadius Ahouansou commented on SOLR-7888:
--
Thank you [~mikemccand]
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Attachments: SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
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-7888) Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a BooleanQuery filter parameter available in Solr
[
https://issues.apache.org/jira/browse/SOLR-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662524#comment-14662524
]
Arcadius Ahouansou commented on SOLR-7888:
--
Hello [~janhoy]
The contextField used in the tests is defined as a simple string in the schema.
We could make things more flexible by defining the type of the field ...
similar to the suggestAnalyzerFieldType config.
I have added this to my todo list.
Is it OK to have the basic usable functionality out and then, create more
tickets to implement further enhancements?
Thank you very much.
Arcadius.
Make Lucene's AnalyzingInfixSuggester.lookup() method that takes a
BooleanQuery filter parameter available in Solr
--
Key: SOLR-7888
URL: https://issues.apache.org/jira/browse/SOLR-7888
Project: Solr
Issue Type: New Feature
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
Attachments: SOLR-7888.patch
LUCENE-6464 has introduced a very flexible lookup method that takes as
parameter a BooleanQuery that is used for filtering results.
This ticket is to expose that method to Solr.
This would allow user to do:
{code}
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:tennis
/suggest?suggest=truesuggest.build=truesuggest.q=termsuggest.contextFilterQuery=contexts:golf
AND contexts:football
{code}
etc
Given that the context filtering in currently only implemented by the
{code}AnalyzingInfixSuggester{code} and by the
{code}BlendedInfixSuggester{code}, this initial implementation will support
only these 2 lookup implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2547 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2547/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: document count mismatch. control=324 sum(shards)=323 cloudClient=323 Stack Trace: java.lang.AssertionError: document count mismatch. control=324 sum(shards)=323 cloudClient=323 at __randomizedtesting.SeedInfo.seed([DB40585DCE59AEF1:5314678760A5C309]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1296) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:233) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5120 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5120/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([AD0E42FB829A4158]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=13202, name=searcherExecutor-6088-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=13202, name=searcherExecutor-6088-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([AD0E42FB829A4158]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=13202,
[jira] [Commented] (SOLR-7895) Administrative UI Lacks Obvious Delete Core Contents Button
[ https://issues.apache.org/jira/browse/SOLR-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661387#comment-14661387 ] Shalin Shekhar Mangar commented on SOLR-7895: - Delete All has been this way since Lucene 2.9 Administrative UI Lacks Obvious Delete Core Contents Button - Key: SOLR-7895 URL: https://issues.apache.org/jira/browse/SOLR-7895 Project: Solr Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Aaron Greenspan When Solr screws up, which is practically on a daily basis, I often want to delete the contents of a core without deleting its structure. Instead of clicking on a button and perhaps an Are you sure? prompt, I have to remember this incredibly unwieldy and dangerous-to-bookmark URL: http://[server]:8983/solr/[core name]/update?stream.body=%3Cdelete%3E%3Cquery%3Eid:*%3C/query%3E%3C/delete%3Ecommit=true To say that this is not user-friendly is a gross understatement. If there is a better way or an obvious easy way, I have not found it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Ant 1.9 not acceptable to smoketester?
I've successfully used the smoketester on release candidates many times with Ant 1.9 (packaged with Ubuntu 14), but when I tried nightly-smoke tonight on branch_5x, it failed: [smoker] RuntimeError: JAR file /home/elyograg/asf/branch_5x/lucene/build/smokeTestRelease/tmp/unpack/lucene-5.4.0/memory/lucene-memory-5.4.0.jar is missing Ant-Version: Apache Ant 1.8 inside its META-INF/MANIFEST.MF Is this expected? Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7895) Administrative UI Lacks Obvious Delete Core Contents Button
[ https://issues.apache.org/jira/browse/SOLR-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661386#comment-14661386 ] Upayavira commented on SOLR-7895: - I don't, but it would have been on a 5.2.1 index that I saw it happen. I was pleasantly surprised myself. Administrative UI Lacks Obvious Delete Core Contents Button - Key: SOLR-7895 URL: https://issues.apache.org/jira/browse/SOLR-7895 Project: Solr Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Aaron Greenspan When Solr screws up, which is practically on a daily basis, I often want to delete the contents of a core without deleting its structure. Instead of clicking on a button and perhaps an Are you sure? prompt, I have to remember this incredibly unwieldy and dangerous-to-bookmark URL: http://[server]:8983/solr/[core name]/update?stream.body=%3Cdelete%3E%3Cquery%3Eid:*%3C/query%3E%3C/delete%3Ecommit=true To say that this is not user-friendly is a gross understatement. If there is a better way or an obvious easy way, I have not found it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7895) Administrative UI Lacks Obvious Delete Core Contents Button
[ https://issues.apache.org/jira/browse/SOLR-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661380#comment-14661380 ] Shawn Heisey commented on SOLR-7895: bq. Once a commit happens, Lucene notices that there are no segments left, and you are left with an entirely empty index. Do you happen to know when this optimization was added? Last time I explicitly checked (which I admit was quite a while ago), deleting all the docs in the index didn't clear up disk space. When my build program starts a full rebuild (with DIH), I have it do the following sequence on each build core: delete all docs, commit, optimize, and then reload the core. That takes care of the disk space... but if I had the option, I'd delete the data directory and reload. The build program runs on another host and only connects with SolrJ, there is no filesystem access. Administrative UI Lacks Obvious Delete Core Contents Button - Key: SOLR-7895 URL: https://issues.apache.org/jira/browse/SOLR-7895 Project: Solr Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Aaron Greenspan When Solr screws up, which is practically on a daily basis, I often want to delete the contents of a core without deleting its structure. Instead of clicking on a button and perhaps an Are you sure? prompt, I have to remember this incredibly unwieldy and dangerous-to-bookmark URL: http://[server]:8983/solr/[core name]/update?stream.body=%3Cdelete%3E%3Cquery%3Eid:*%3C/query%3E%3C/delete%3Ecommit=true To say that this is not user-friendly is a gross understatement. If there is a better way or an obvious easy way, I have not found it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661424#comment-14661424 ] ASF subversion and git services commented on LUCENE-6417: - Commit 1694614 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1694614 ] LUCENE-6417: Upgrade ANTLR used in expressions module to version 4.5 Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Assignee: Uwe Schindler Attachments: LUCENE-6417.patch, LUCENE-6417.patch, LUCENE-6471.patch, LUCENE-6471.patch, LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-4316: Attachment: SOLR-4316.patch Patch that separates out collection specific tabs from core specific tabs, when in cloud mode Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, solrcloud-admin-ui-menu.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661440#comment-14661440
]
ASF subversion and git services commented on SOLR-7760:
---
Commit 1694616 from [~teofili] in branch 'dev/trunk'
[ https://svn.apache.org/r1694616 ]
SOLR-7760 - fixed method visibility in UimaUpdateRP and SolrUimaConfiguration
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7886) factor out a TestMiniSolrCloudClusterBase class
[
https://issues.apache.org/jira/browse/SOLR-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661463#comment-14661463
]
Gregory Chanan commented on SOLR-7886:
--
I believe that's the idea behind the jira. Though there may be cases where
extending is justified, e.g. in the case where you want to run the same tests
with a different configuration.
factor out a TestMiniSolrCloudClusterBase class
---
Key: SOLR-7886
URL: https://issues.apache.org/jira/browse/SOLR-7886
Project: Solr
Issue Type: Test
Reporter: Christine Poerschke
Priority: Minor
Please see SOLR-7877 for initial discussion on this.
Currently we have:
{code}
public class TestMiniSolrCloudCluster extends LuceneTestCase
{code}
and
{code}
public class BasicAuthIntegrationTest extends TestMiniSolrCloudCluster {
public class TestAuthenticationFramework extends TestMiniSolrCloudCluster {
public class TestMiniSolrCloudClusterKerberos extends
TestMiniSolrCloudCluster {
{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
[jira] [Commented] (SOLR-7838) Implement a RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661461#comment-14661461
]
Jan Høydahl commented on SOLR-7838:
---
Cool, I did not notice the parent when I wrote the comment, it all makes sense
now. Sorry for jumping to conclusions :(
Implement a RuleBasedAuthorizationPlugin
Key: SOLR-7838
URL: https://issues.apache.org/jira/browse/SOLR-7838
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
h2. authorization plugin
This would store the roles of various users and their privileges in ZK
sample authorization.json
{code:javascript}
{
authorization: {
class: solr.ZKAuthorization,
roles :{
john : [admin]
david : [guest,dev]
}
permissions: {
collection-edit: {
role: admin
},
coreadmin:{
role:admin
},
config-edit: {
//all collections
role: admin,
method:POST
},
schema-edit: {
roles: admin,
method:POST
},
update: {
//all collections
role: dev
},
mycoll_update: {
collection: mycoll,
path:[/update/*],
role: [somebody]
}
}
}
}
{code}
This also supports editing of the configuration through APIs
Example 1: add or remove roles
{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H
'Content-type:application/json' -d '{
set-user-role: {tom:[admin,dev},
set-user-role: {harry:null}
}'
{code}
Example 2: add or remove permissions
{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H
'Content-type:application/json'-d '{
set-permission: { name:a-custom-permission-name,
collection:gettingstarted,
path:/handler-name,
before: name-of-another-permission
},
delete-permission:permission-name
}'
{code}
Please note that you have to replace the whole permission each time it is
edited. The API does not support editing one property at a time. Use the
'before' property to re-order your permissions
Example 3: Restrict collection admin operations (writes only) to be performed
by an admin only
{code}
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H
'Content-type:application/json' -d '{
set-permission : {name:collection-admin-edit, role:admin}}'
{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
[jira] [Updated] (SOLR-7889) Secure ZooKeeper should be easy and the default
[
https://issues.apache.org/jira/browse/SOLR-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7889:
--
Description:
ZooKeeper security is documented at
https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control but
is not trivial to setup, see http://search-lucene.com/m/eHNlqr6EnMrP6O
As we enable more and more security stuff, securing ZK should be easier to do
and ideally the default. This is an umbrella for such improvements.
When all of this is in place and working, perhaps even Solr should refuse to
start if Auth/Autz plugins are in use and ZK communication is not properly
protected, e.g. require {{bin/solr start --insecure}} to override.
was:
ZooKeeper security is documented at
https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control but
is not trivial to setup, see http://search-lucene.com/m/eHNlqr6EnMrP6O
As we enable more and more security stuff, securing ZK should be easier to do
and ideally the default.
The {{DefaultZkACLProvider}} should by default require admin access for all
operations including read of {{/security.json}}, and other sensitive paths.
Today this is left to the user to implement.
Move manual env-var instructions from documentation into start scripts, with
defaults for read-only and admin user passwords.
Perhaps even Solr should refuse to start if ZK communication is not ACL
protected, encrypted and if default admin passwd is not changed. Overrideable
with a new option {{bin/solr start --insecure}}
Let this JIRA be an umbrella for several child tasks.
Secure ZooKeeper should be easy and the default
---
Key: SOLR-7889
URL: https://issues.apache.org/jira/browse/SOLR-7889
Project: Solr
Issue Type: Improvement
Components: security
Reporter: Jan Høydahl
Priority: Critical
Labels: security, zookeeper
ZooKeeper security is documented at
https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control but
is not trivial to setup, see http://search-lucene.com/m/eHNlqr6EnMrP6O
As we enable more and more security stuff, securing ZK should be easier to do
and ideally the default. This is an umbrella for such improvements.
When all of this is in place and working, perhaps even Solr should refuse to
start if Auth/Autz plugins are in use and ZK communication is not properly
protected, e.g. require {{bin/solr start --insecure}} to override.
--
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-7893) Enable SSL to ZooKeeper by default
[
https://issues.apache.org/jira/browse/SOLR-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661486#comment-14661486
]
Jan Høydahl commented on SOLR-7893:
---
Seems no-one are working on ZOOKEEPER-235 etc at the moment :-(
Enable SSL to ZooKeeper by default
--
Key: SOLR-7893
URL: https://issues.apache.org/jira/browse/SOLR-7893
Project: Solr
Issue Type: Sub-task
Components: security
Reporter: Jan Høydahl
Labels: ssl, zookeeper
Fix For: Trunk
Once ZooKeeper supports SSL properly, Solr should start using it for all
communication. See comments in
https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
{quote}
ZooKeeper does not support encrypted communication with clients like Solr.
There are several related JIRA tickets where SSL support is being
planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and
ZOOKEEPER-1000.
{quote}
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661445#comment-14661445
]
Shalin Shekhar Mangar commented on SOLR-7760:
-
bq. thanks Aaron for your patch, it's been committed to trunk and backported to
branch 5.x therefore you'll find it in the next 5.x release.
Note the 5.3 branch has already been created so unless you backport this
commit, it won't make it to the next release (5.3)
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3, Trunk
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-4316: Attachment: collections menu open.png Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-4316: Attachment: cores menu open.png Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, collections menu open.png, cores menu open.png, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661473#comment-14661473
]
Jan Høydahl commented on SOLR-7642:
---
bq. What I don't like about it is that things like typos in connection strings
just create new zk nodes and start a fresh zk state tree
So how about we auto-create the chroot only if it == {{/solr}}. That will
probably be the case for 90%, and there should be no reason to believe the
chroot was chosen on accident. Then we could recommend always using a chroot of
{{/solr}}, and document that for advanced cases, e.g. reusing the same ZK
ensemble for multiple Solr clusters, you need to create other chroots
manually...
Should launching Solr in cloud mode using a ZooKeeper chroot create the
chroot znode if it doesn't exist?
-
Key: SOLR-7642
URL: https://issues.apache.org/jira/browse/SOLR-7642
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Priority: Minor
If you launch Solr for the first time in cloud mode using a ZooKeeper
connection string that includes a chroot leads to the following
initialization error:
{code}
ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
in ZkHost but the znode doesn't exist. localhost:2181/lan
at
org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
at
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
{code}
The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
to create the chroot znode (bootstrap action does this).
I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
is that some violation of using a chroot?
--
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] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-4470. - Resolution: Duplicate Closing this as Basic auth has been implemented through the generic plugins. Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2544 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2544/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([E015E369B38C9F3A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236) at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10594 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2 Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/build/solr-core/test/J1/temp/solr.cloud.HttpPartitionTest_E015E369B38C9F3A-001/init-core-data-001 [junit4] 2 1015915 INFO (SUITE-HttpPartitionTest-seed#[E015E369B38C9F3A]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 1015917 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 1015918 INFO (Thread-2341) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 1015918 INFO (Thread-2341) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 1016020 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.ZkTestServer start zk server on port:64120 [junit4] 2 1016021 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 1016022 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 1016031 INFO (zkCallback-731-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@ea52178 name:ZooKeeperConnection Watcher:127.0.0.1:64120 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1016031 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 1016031 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 1016031 INFO (TEST-HttpPartitionTest.test-seed#[E015E369B38C9F3A]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2
RE: Ant 1.9 not acceptable to smoketester?
Yes, this is expected. Like with the Java version used to compile, the official release artifacts must be created with the official toolchain. So JDK 1.7 for compiling branch_5x and the Ant 1.8.x for build. Policeman Jenkins (Ubuntu 14) downloads ANT through Jenkins. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Friday, August 07, 2015 8:08 AM To: dev@lucene.apache.org Subject: Ant 1.9 not acceptable to smoketester? I've successfully used the smoketester on release candidates many times with Ant 1.9 (packaged with Ubuntu 14), but when I tried nightly-smoke tonight on branch_5x, it failed: [smoker] RuntimeError: JAR file /home/elyograg/asf/branch_5x/lucene/build/smokeTestRelease/tmp/unp ack/lucene-5.4.0/memory/lucene-memory-5.4.0.jar is missing Ant-Version: Apache Ant 1.8 inside its META-INF/MANIFEST.MF Is this expected? Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661427#comment-14661427 ] ASF subversion and git services commented on LUCENE-6417: - Commit 1694615 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1694615 ] Merged revision(s) 1694614 from lucene/dev/trunk: LUCENE-6417: Upgrade ANTLR used in expressions module to version 4.5 Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Assignee: Uwe Schindler Attachments: LUCENE-6417.patch, LUCENE-6417.patch, LUCENE-6471.patch, LUCENE-6471.patch, LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661426#comment-14661426 ] Shawn Heisey commented on SOLR-7880: Tests and precommit passed. Several random bin\solr commands also worked. After fixing the script to accept Ant 1.9, nightly-smoke passed too. Update commons-cli to 1.3.1, fix usage of deprecated classes/methods Key: SOLR-7880 URL: https://issues.apache.org/jira/browse/SOLR-7880 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 5.2.1 Reporter: Shawn Heisey Assignee: Shawn Heisey Fix For: 5.4 Attachments: SOLR-7880.patch, SOLR-7880.patch, SOLR-7880.patch While looking at SOLR-7847, I noticed that commons-cli was an old version, and once I upgraded it in the ivy config, found that SolrCLI is using deprecated classes/methods. This issue is to complete the upgrade and fix the deprecations. -- 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-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-6417. --- Resolution: Fixed Thanks Jack! Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Assignee: Uwe Schindler Attachments: LUCENE-6417.patch, LUCENE-6417.patch, LUCENE-6471.patch, LUCENE-6471.patch, LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661444#comment-14661444 ] Shalin Shekhar Mangar commented on SOLR-4316: - bq. The schema browser really is the only tab we have at the moment that is ambiguous - the schema is shared across a collection, but the term info is core specific Right but schema really only belongs in a cloud tab. The term info is index specific. Perhaps we can rename the existing Segment Info page to Index Info and add the Field Selector + Term Info in there? Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- 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-4316) Admin UI - SolrCloud - extend core options to collections
[ https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-4316: Attachment: two-selectors.png Admin UI - SolrCloud - extend core options to collections - Key: SOLR-4316 URL: https://issues.apache.org/jira/browse/SOLR-4316 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.1 Reporter: Shawn Heisey Assignee: Upayavira Fix For: 4.9, Trunk Attachments: SOLR-4316.patch, SOLR-4316.patch, solrcloud-admin-ui-menu.png, two-selectors.png There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see. A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6728) Add clean as a dependency on precommit
Shawn Heisey created LUCENE-6728: Summary: Add clean as a dependency on precommit Key: LUCENE-6728 URL: https://issues.apache.org/jira/browse/LUCENE-6728 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 5.2 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Trivial Fix For: 5.4 I think that precommit should depend on clean. On branch_5x, I started a precommit, then realized partway through that I was running with Java 8. I interrupted the precommit, changed JAVA_HOME to point at Java 7, and started it again. After a few minutes, the forbidden-api check failed because it couldn't find a class. Is there any situation where a clean should NOT be done before starting precommit? -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-5756: Attachment: SOLR-5756.patch Patch updated to trunk. I'm running tests and precommit now. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.4 Attachments: SOLR-5756-part2.patch, SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7728) bin/solr script: add port number to GC log filename
[ https://issues.apache.org/jira/browse/SOLR-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661485#comment-14661485 ] Gregory Chanan commented on SOLR-7728: -- +1 patch looks generally good to me. It looks like you generated the patch from solr/bin -- can you regenerate it from the root? For 5.x branch, making it an option sounds like a good idea. Want to put up a patch for that, Michael? bin/solr script: add port number to GC log filename --- Key: SOLR-7728 URL: https://issues.apache.org/jira/browse/SOLR-7728 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 5.2.1 Reporter: Crawdaddy Assignee: Gregory Chanan Attachments: SOLR-7728.patch It'd be nice if the bin/solr script added the node's port number to the GC log file name in the same way it does for the console log. This helps those of us who run multiple nodes per machine match node - log. -- 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-7898) Administrative Interface Should Steam Incoming Queries and Results Per Core
[ https://issues.apache.org/jira/browse/SOLR-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661506#comment-14661506 ] Jan Høydahl commented on SOLR-7898: --- This may be too sensitive info to put in our admin as long as it is open to everybody. And in many cases the queries coming in to Solr will be different from and less interesting than the queries entered in the User's search application. That's perhaps why most people implement search analytics logging on the application level (their web front end) instead of at solr-level. Administrative Interface Should Steam Incoming Queries and Results Per Core --- Key: SOLR-7898 URL: https://issues.apache.org/jira/browse/SOLR-7898 Project: Solr Issue Type: New Feature Components: web gui Affects Versions: 5.2.1 Reporter: Aaron Greenspan Priority: Minor It would be helpful for debugging purposes (and kind of cool) to see the queries coming into Solr and the results found for each in a tail -f style streaming interface on the administrative web site. I'm pretty sure this information is logged anyway... -- 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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili reassigned SOLR-7760:
-
Assignee: Tommaso Teofili
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661442#comment-14661442
]
Tommaso Teofili commented on SOLR-7760:
---
thanks Aaron for your patch, it's been committed to trunk and backported to
branch 5.x therefore you'll find it in the next 5.x release.
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3, Trunk
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved SOLR-7760.
---
Resolution: Fixed
Fix Version/s: Trunk
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3, Trunk
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7896) Solr Administrative Interface Lacks Password Protection
[ https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661410#comment-14661410 ] Shawn Heisey commented on SOLR-7896: Regarding SSL on by default ... while this would provide some security out of the box, it annoys me when I try to connect to a web interface and I am immediately greeted by a security warning regarding a certificate that doesn't validate. An experienced user knows that it is safe to ignore that warning and proceed anyway, but a beginner may misinterpret what their browser is telling them, decide that Solr has security problems, and go looking for a different solution. I would rather present an insecure interface out of the box so that a new user can *immediately* see that their install is operational. I'd be OK with a warning box on every page telling the user that they should enable SSL, as long as it could be removed with a config change. Turning on SSL should be very easy for a novice to do. Another piece that must be straightforward is the installation of a custom certificate that the user might get from a public CA, and any required intermediate certificates. As already mentioned, we have a framework for authentication coming in 5.3. Once we are sure it's stable and effective, turning on authentication for the admin UI by default would be a good idea. The out-of-the-box credentials should be easy to locate on our website, in the first few pages of the documentation, and one or more of the .txt files included in the download. Solr Administrative Interface Lacks Password Protection --- Key: SOLR-7896 URL: https://issues.apache.org/jira/browse/SOLR-7896 Project: Solr Issue Type: Bug Components: security, web gui Affects Versions: 5.2.1 Reporter: Aaron Greenspan Priority: Critical Out of the box, the Solr interface should require an administrative password that the user is required to set. Apparently there are ways of configuring Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced Linux admin and a programmer; I've tried, numerous times, and I've not once been able to get it to work. The point is this, though: *No one should have to try to get their Solr instance to support password authentication and preferably SSL (even if it's just with a self-signed certificate). Solr is designed to store huge amounts of data and is therefore a likely target for malicious users.* This needs to be addressed! It's 2015 and Solr is on version 5! -- 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-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13761 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13761/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseParallelGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([EAC97DC7D3728592:4D8DC563BEC9962B]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661441#comment-14661441
]
ASF subversion and git services commented on SOLR-7760:
---
Commit 1694617 from [~teofili] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694617 ]
SOLR-7760 - fixed method visibility in UimaUpdateRP and SolrUimaConfiguration
(branch 5.x)
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661448#comment-14661448
]
Tommaso Teofili edited comment on SOLR-7760 at 8/7/15 7:36 AM:
---
bq. Note the 5.3 branch has already been created
right Shalin, I didn't notice that so yes, it'll be on 5.4 then (I don't think
it's crucial to have it in 5.3).
was (Author: teofili):
bq. Note the 5.3 branch has already been created
right Shaling, I didn't notice that so yes, it'll be on 5.4 then (I don't think
it's crucial to have it in 5.3).
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3, Trunk
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration
[
https://issues.apache.org/jira/browse/SOLR-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661448#comment-14661448
]
Tommaso Teofili commented on SOLR-7760:
---
bq. Note the 5.3 branch has already been created
right Shaling, I didn't notice that so yes, it'll be on 5.4 then (I don't think
it's crucial to have it in 5.3).
Fix method and field visibility for UIMAUpdateRequestProcessor and
SolrUIMAConfiguration
Key: SOLR-7760
URL: https://issues.apache.org/jira/browse/SOLR-7760
Project: Solr
Issue Type: Improvement
Components: contrib - UIMA
Affects Versions: 5x
Reporter: Aaron LaBella
Assignee: Tommaso Teofili
Priority: Critical
Fix For: 5.3, Trunk
Attachments: SOLR-7760.patch
The methods in
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
are not public and they need to be for other code to be able to make use of
the configuration data, ie: mapped fields. Likewise,
{{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
does not have an accessor for the SolrUIMAConfiguration object
--
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-7728) bin/solr script: add port number to GC log filename
[ https://issues.apache.org/jira/browse/SOLR-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan reassigned SOLR-7728: Assignee: Gregory Chanan bin/solr script: add port number to GC log filename --- Key: SOLR-7728 URL: https://issues.apache.org/jira/browse/SOLR-7728 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 5.2.1 Reporter: Crawdaddy Assignee: Gregory Chanan Attachments: SOLR-7728.patch It'd be nice if the bin/solr script added the node's port number to the GC log file name in the same way it does for the console log. This helps those of us who run multiple nodes per machine match node - log. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Ant 1.9 not acceptable to smoketester?
On 8/7/2015 1:07 AM, Uwe Schindler wrote: Yes, this is expected. Like with the Java version used to compile, the official release artifacts must be created with the official toolchain. So JDK 1.7 for compiling branch_5x and the Ant 1.8.x for build. Policeman Jenkins (Ubuntu 14) downloads ANT through Jenkins. The comment in the script implies (but does not explicitly state) that 1.9 is OK: # Make sure 1.8 ant was used to build release bits: (this will match 1.8+) Trunk has the same definition and the same comment, and also fails with Ant 1.9. Although an alternate version of Ant can be utilized by changing ANT_HOME, similar to JAVA_HOME, I wonder if it would be too much of a headache to require different versions in trunk and stable. The 1.9 version has been out for two years, so I think we're going to have to update eventually. Switching trunk now might be a good idea, so it's good and tested by the time we get to 6.0. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Eerdekens updated LUCENE-6725: -- Attachment: lucene-3.5-ant-test-results.txt My first test run, for Lucene 3.5 on our test environment, already causes the same JVM crashes (SIGSEGV on IndexFileNames.segmentFileName) as we saw when triggering a reindex in Liferay on production. What files should I provide: just the console output of the test, all the hs_err_pid files or even the whole test subdirectory? Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- 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-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661540#comment-14661540 ] Dawid Weiss commented on LUCENE-6725: - Also, if possible, I'd re-run the tests with the newest JVM from Oracle -- 7u80... this may be something already resolved. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- 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-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661537#comment-14661537 ] Dawid Weiss commented on LUCENE-6725: - Can you try with a newer Lucene first? It contains better error reporting so that maybe we can isolate it (perhaps we can just run a single class instead of the entire suite of tests). We can't really throw the entire build at the JVM folks -- it's too much work narrowing it down. If this doesn't work, we'll try to narrow it down with 3.5. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- 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-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13763 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13763/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCryptoKeys Error Message: ERROR: SolrIndexSearcher opens=99 closes=98 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=99 closes=98 at __randomizedtesting.SeedInfo.seed([ECD625021735525A]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCryptoKeys Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.TestCryptoKeys: 1) Thread[id=883, name=searcherExecutor-543-thread-1, state=WAITING, group=TGRP-TestCryptoKeys] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)2) Thread[id=551, name=qtp552738483-551, state=RUNNABLE, group=TGRP-TestCryptoKeys] at java.util.WeakHashMap.get(WeakHashMap.java:403) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:101) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:219) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:454) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[jira] [Commented] (LUCENE-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661559#comment-14661559 ] Uwe Schindler commented on LUCENE-6725: --- I would suggest to update to Java 8u51. I have an instance of Liferay (recent version) running in production with Java 8. This performs much better (faster), maybe that also solves the issue. Alternatively use Java 7u80. In General, I am thinking about installing a VM with OpenSolaris on Policeman Jenkins (http://jenkins.thetaphi.de), but this could also be related to SPARC platform... SPARC is much more sensible to unaligned accesses to memory and SIGSEGV/SIGBUS earlier. But this is a problem with Oracle's JDK. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661559#comment-14661559 ] Uwe Schindler edited comment on LUCENE-6725 at 8/7/15 9:39 AM: --- I would suggest to update to Java 8u51. I have an instance of Liferay (recent version) running in production with Java 8. This performs much better (faster), maybe that also solves the issue. Alternatively use Java 7u80. In General, I am thinking about installing a VM with OpenSolaris on Policeman Jenkins (http://jenkins.thetaphi.de), but this bug may also be related to SPARC platform... SPARC is much more sensible to unaligned accesses to memory and SIGSEGV/SIGBUS earlier. But this is a problem with Oracle's JDK. was (Author: thetaphi): I would suggest to update to Java 8u51. I have an instance of Liferay (recent version) running in production with Java 8. This performs much better (faster), maybe that also solves the issue. Alternatively use Java 7u80. In General, I am thinking about installing a VM with OpenSolaris on Policeman Jenkins (http://jenkins.thetaphi.de), but this could also be related to SPARC platform... SPARC is much more sensible to unaligned accesses to memory and SIGSEGV/SIGBUS earlier. But this is a problem with Oracle's JDK. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_51) - Build # 4989 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4989/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 29932 lines...] check-licenses: [echo] License check under: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr [licenses] MISSING sha1 checksum file for: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\lib\antlr4-runtime-4.5.jar [licenses] EXPECTED sha1 checksum file : C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\licenses\antlr4-runtime-4.5.jar.sha1 [...truncated 3 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:726: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:117: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build.xml:313: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\tools\custom-tasks.xml:62: License check failed. Check the logs. If you recently modified ivy-versions.properties or any module's ivy.xml, make sure you run ant clean-jars jar-checksums before running precommit. Total time: 76 minutes 40 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661611#comment-14661611 ] Per Steffensen commented on SOLR-4470: -- Hopefully I will soon have the time to see if this other implementation will fulfill our needs. But closing SOLR-4470 for now is fine Support for basic http auth in internal solr requests - Key: SOLR-4470 URL: https://issues.apache.org/jira/browse/SOLR-4470 Project: Solr Issue Type: New Feature Components: clients - java, multicore, replication (java), SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: Trunk Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.patch We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node. It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make internal request to other Solr-nodes, and for it to work credentials need to be provided here also. Ideally we would like to forward credentials from a particular request to all the internal sub-requests it triggers. E.g. for search and update request. But there are also internal requests * that only indirectly/asynchronously triggered from outside requests (e.g. shard creation/deletion/etc based on calls to the Collection API) * that do not in any way have relation to an outside super-request (e.g. replica synching stuff) We would like to aim at a solution where original credentials are forwarded when a request directly/synchronously trigger a subrequest, and fallback to a configured internal credentials for the asynchronous/non-rooted requests. In our solution we would aim at only supporting basic http auth, but we would like to make a framework around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest) We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible. -- 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-6273) Cross Data Center Replication
[ https://issues.apache.org/jira/browse/SOLR-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661623#comment-14661623 ] Shalin Shekhar Mangar commented on SOLR-6273: - Before we release 5.3, we should move this issue out of the 5.3 section and move it to 6.0.0 until it is backported. Cross Data Center Replication - Key: SOLR-6273 URL: https://issues.apache.org/jira/browse/SOLR-6273 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Assignee: Erick Erickson Attachments: SOLR-6273-trunk-testfix1.patch, SOLR-6273-trunk-testfix2.patch, SOLR-6273-trunk-testfix3.patch, SOLR-6273-trunk.patch, SOLR-6273-trunk.patch, SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch This is the master issue for Cross Data Center Replication (CDCR) described at a high level here: http://heliosearch.org/solr-cross-data-center-replication/ -- 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-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661626#comment-14661626 ] Joel Bernstein commented on LUCENE-6722: The SQL Interface (SOLR-7560) is currently in trunk. This feature was originally slated for Solr 5.3 but I had to revert because the Presto libraries relied on Java 8. I now have a version that uses Calcite instead of Presto almost ready to release with Solr 5.4. If 6.0 is really that close I'm inclined to release the Presto code that is already in trunk with Solr 6. I'll just work on new features of the SQL interface in trunk until the 6.0 release. I've been holding off on updating the CHANGES.txt until I successfully backported to 5x, but if the decision is made to release trunk in the next couple months of I can just add all the tickets involved in the SQL interface under Solr 6 changes. Java 8 as the minimum supported JVM version for branch_5x - Key: LUCENE-6722 URL: https://issues.apache.org/jira/browse/LUCENE-6722 Project: Lucene - Core Issue Type: Wish Reporter: Shalin Shekhar Mangar Priority: Blocker Fix For: 5.4 Require Java 8 as the minimum supported JVM version for branch_5x. # Java 7 is already EOL'ed # Trunk is already at Java8 # Important Solr components such as Jetty 9.3.x already require Java 8 # Nashorn Javascript engine available in Java 8 is just so much faster and we may see more usage of JS inside Solr (SOLR-7576 etc.) -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661636#comment-14661636
]
Christine Poerschke commented on SOLR-7766:
---
Working on merging this from {{trunk}} to {{branch_5x}} - some minor merge
conflicts need resolving.
also still to do: merge to {{lucene_solr_5_3}} or move this issue out of the
5.3 {{CHANGES.txt}} section ([~shalinmangar] just created the 5.4 section -
thank you!)
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch, SOLR-7766.txt
By supplying the special value of EMPTY for the createNodeSet parameter (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=EMPTYname=myCollection...}})
a collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5687) Enabling Solr Security By Using Servlet Filter in SolrCloud Env
[ https://issues.apache.org/jira/browse/SOLR-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-5687. - Resolution: Won't Fix Resolving as Won't fix since we now have a working security plugin system. If you disagree, please feel free to reopen. Enabling Solr Security By Using Servlet Filter in SolrCloud Env --- Key: SOLR-5687 URL: https://issues.apache.org/jira/browse/SOLR-5687 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Senthil Nathan When trying to enabling solr security by using servlet filter (Spring Security) Replication Failed and exception was throwing from solrjclient . Solution to the above problem is to - Upgrade apache httpclient libs from 4.2.3 to 4.3.2 modify the HttpClientUtil, HttpClientConfigurer to support 4.3.2 client. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-5756: Attachment: SOLR-5756.patch # I changed the Collection API from using name to collection which, to me, seems much more clear. # I added a end-to-end test in TestCollectionAPI to migrate state format using the new collection API. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: Trunk, 5.4 Attachments: SOLR-5756-part2.patch, SOLR-5756-trunk.patch, SOLR-5756.patch, SOLR-5756.patch, SOLR-5756.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7576) Implement RequestHandler in Javascript
[ https://issues.apache.org/jira/browse/SOLR-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661362#comment-14661362 ] Noble Paul edited comment on SOLR-7576 at 8/7/15 11:37 AM: --- bq.There are other features like sources for Suggesters that I look forward to seeing getting upgraded to use the blob store Exactly. That was the reason why I created that API. We need a place where we can store MBs of files and multiple versions of each of them. So a developer should be able to edit without fear and play with his production cluster without impacting his actual users bq.For this specific feature (request handlers in scripting language) why should the executable be put in the Blob store at all? Generally these scripts are going to be very small. I don't know if they are going to be very small and neither do you. In general we need a place which can store a lot of files. Moreover, whether the file is big or small the user experience is going to be exactly same, he will have to run a command line to edit this. Keeping multiple versions of the same script in the conf directory is not what I call elegant. We are just thinking of ZK as a kitchen sink because it used to be file system for standlone solr and size was never a problem Standalone Solr is not going to be the primary target for any new feature that we develop. In a not too distant future we will make the standalone Solr also use a ZK and other stuff to unify dev/user experience. After all a standalone solr can easily be a single collection/ single shard/single replica version of SolrCloud. bq. A REST API on top could add another convenient access mechanism to conf dir stuff Please , we are not going to add more stuff to conf dir. That is a slippery slope. conf dir should have well known standard files. The rest of the stuff should move away. Bloating up ZK just because we used to store things in conf dir is just inertia. We must get over it. Having said that there is nothing that stops us from configuring the JsRequestHandler to load scripts from a local file system directory which can be useful for certain usecases. bq.i.e. exactly how the Script URP works IIRC the script URP does not reload the script automatically by watching the ZK node. You need to go and restart core or other dirty stuff. In a large SolrCloud cluster that amounts to 100's of cores getting reloaded and caches trashed and what not (all queries getting slow/ a lot of GC etc). Do you still like that idea? Let's not assume that whatever we have today is optimized to run on cloud mode. There are a lot of things that got carried forward from the legacy things which are suboptimal to cloud. Instead of clinging on to the old way of life we must modernize our system to adopt the new paradigm was (Author: noble.paul): bq.There are other features like sources for Suggesters that I look forward to seeing getting upgraded to use the blob store Exactly. That was the reason why I created that API. We need a place where we can store MBs of files and multiple versions of each of them. So a developer should be able to edit without fear and play with his production cluster without impacting his actual users bq.For this specific feature (request handlers in scripting language) why should the executable be put in the Blob store at all? Generally these scripts are going to be very small. I don't know if they are going to be very small and neither do you. In general we need a place which can store a lot of files. Moreover, whether the file is big or small the user experience is going to be exactly same, he will have to run a command line to edit this. Keeping multiple versions of the same script in the conf directory is not what I call elegant. We are just thinking of ZK as a kitchen sink because it used to be file system for standlone solr and size was never a problem Standalone Solr is not going to be the primary target for any new feature that we develop. In a not too distant future we will make the standalone Solr also use a ZK and other stuff to unify dev/user experience. After all a standalone solr can easily be a single collection/ single shard/single replica version of SolrCloud. bq. A REST API on top could add another convenient access mechanism to conf dir stuff Please , we are not going to add more stuff to conf dir. That is a slippery slope. conf dir should have well known standard files. The rest of the stuff should move away. Bloating up ZK just because we used to store things in conf dir is just inertia. We must get over it. Having said that there is nothing that stops us from configuring the JsRequestHandler to load scripts from a local file system directory which can be useful for certain usecases. bq.i.e. exactly how the Script URP works IIRC the script URP does not reload the script automatically
[jira] [Commented] (SOLR-1560) make optimize do partial optimizes under the covers
[ https://issues.apache.org/jira/browse/SOLR-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661693#comment-14661693 ] Jan Høydahl commented on SOLR-1560: --- Still relevant? make optimize do partial optimizes under the covers - Key: SOLR-1560 URL: https://issues.apache.org/jira/browse/SOLR-1560 Project: Solr Issue Type: Improvement Components: update Reporter: Hoss Man In Lucene, an optimize() call iteratively merges segments until only one is left - and while it's merging it (ultimately) needs to make a copy of the entire index, because readers attempting to open the index mid-optimize need to see a consistent copy of the index. In Solr, we have control over when new readers/searchers get opened, so what if when we recieved an optimize/ command, we under the covers we made iterative partial optimize calls and only opened a new searcher when we were finished with all of them? In theory this seems like it would help reduce the disk space used during optimize, without really affecting the time it takes to optimize These are the threads that prompted this idea... http://old.nabble.com/eternal-optimize-interrupted-to24805680.html#a24805680 http://old.nabble.com/Re%3A-eternal-optimize-interrupted-to24928754.html#a24928754 http://old.nabble.com/Optimization-of-large-shard-succeeded-to25809281.html#a25809281 -- 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-6725) Reindex crashes the JVM
[ https://issues.apache.org/jira/browse/LUCENE-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661564#comment-14661564 ] Dawid Weiss commented on LUCENE-6725: - Yeah, I think it's the processor/ hardware (and the associated assembly generation) that is the cause here. Reindex crashes the JVM --- Key: LUCENE-6725 URL: https://issues.apache.org/jira/browse/LUCENE-6725 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Solaris 10 1/13 (Update 11) Patchset applied. Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus Memory: 8k page, physical 25165824k(3240848k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (24.75-b04) for solaris-sparc JRE (1.7.0_75-b13) Reporter: Jan Eerdekens Priority: Minor Attachments: hs_err_pid18938.log, lucene-3.5-ant-test-results.txt We're using Liferay which uses Lucene behind the screens to index things like documents, web content, users, etc... . When we trigger a full reindex via the Liferay Control Panel, which uses IndexWriter.deleteAll(), the JVM crashes and generates a dump with the following message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x78de94a8, pid=18938, tid=2478 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode solaris-sparc compressed oops) # Problematic frame: # J 5227 C2 org.apache.lucene.index.IndexFileNames.segmentFileName(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; (44 bytes) @ 0x78de94a8 [0x78de9480+0x28] -- 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
