[jira] [Resolved] (SOLR-13385) Upgrade dependency jackson-databind in solr package contrib/prometheus-exporter/lib
[ https://issues.apache.org/jira/browse/SOLR-13385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-13385. - Resolution: Duplicate Assignee: Kevin Risden Fix Version/s: master (9.0) 8.1 Duplicate of SOLR-13112 > Upgrade dependency jackson-databind in solr package > contrib/prometheus-exporter/lib > --- > > Key: SOLR-13385 > URL: https://issues.apache.org/jira/browse/SOLR-13385 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6, 8.0.1 >Reporter: DW >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > > The current used jackson-databind in > /contrib/prometheus-exporter/lib/jackson-databind-2.9.6.jar has known > Security Vulnerabilities record. Please upgrade to 2.9.8+. Thanks. > > Please let me know if you would like detailed CVE records. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests
[ https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814712#comment-16814712 ] Kevin Risden commented on SOLR-13389: - Big plus one from me. I know I looked at this a bit as part of HDFS tests. I am 99% sure what I put is not correct but it fixed some of the HDFS tests. https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java#L115 This is just conjecture, but I think there might be some weirdness with the HTTP2 handling of sockets compared to HTTP 1.1. I just have that hunch based on some of the errors I've seen. > rectify discrepencies in socket (and connect) timeout values used throughout > the code and tests - probably helping to reduce TimeoutExceptions in tests > --- > > Key: SOLR-13389 > URL: https://issues.apache.org/jira/browse/SOLR-13389 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > > While looking into some jenkins test failures caused by distributed requests > that timeout, i realized that the "socket timeout" aka "idle timeout" aka > "SO_TIMEOUT" values used in various places in the code & sample configs can > vary significantly, and in the case of *test* configs/code can differ from > the default / production configs by an order of magnitude. > I think we should consider rectifying some of the various places/ways that > different values are sprinkled through out the code to reduce the number of > (different) places we have magic constants. I believe a large number of > jenkins test failures we currently see due to timeout exceptions are simply > because tests (or test configs) override sensible defaults w/values that are > too low to be useful. > (NOTE: all of these problems / discrepancies also apply to "connect timeout" > which should probably be addressed at the same time, but for now i'm focusing > on the "socket timeout" since it seems to be the bigger problem in jenkins > failures -- if we reach consensus on standardizing some values across the > board the same approach can be made to connect timeouts at the same time) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13396) SolrCloud will delete the core data for any core that is not referenced in the clusterstate
[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816367#comment-16816367 ] Kevin Risden commented on SOLR-13396: - I agree that arbitrarily deleting data is bad. The other issue is how do you clean up if you JUST have the error/warn. Would be nice to know what you needed to do in addition that it was a problem. So I will caveat this by saying I have no idea how this works today, but when I read this I thought it would make sense for each node responsible for a shard/collection would have to "ack" that the operation was complete. If the node was down at the time, when it comes up it should know it needs to do "xyz" and finish the operation. Again not sure of the ZK details, but some rough ideas: * Create a znode for each node with list of operations it needs to complete - this would be written to by the leader? * Keep track of which operations each node completed on existing list before deleting? - I think this could be hard since leader could change? Some of the concerns would be added load on ZK for reading/writing operations. The above could have already been thought about when building Solr Cloud so it might be a nonstarter. > SolrCloud will delete the core data for any core that is not referenced in > the clusterstate > --- > > Key: SOLR-13396 > URL: https://issues.apache.org/jira/browse/SOLR-13396 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.3.1, 8.0 >Reporter: Shawn Heisey >Priority: Major > > SOLR-12066 is an improvement designed to delete core data for replicas that > were deleted while the node was down -- better cleanup. > In practice, that change causes SolrCloud to delete all core data for cores > that are not referenced in the ZK clusterstate. If all the ZK data gets > deleted or the Solr instance is pointed at a ZK ensemble with no data, it > will proceed to delete all of the cores in the solr home, with no possibility > of recovery. > I do not think that Solr should ever delete core data unless an explicit > DELETE action has been made and the node is operational at the time of the > request. If a core exists during startup that cannot be found in the ZK > clusterstate, it should be ignored (not started) and a helpful message should > be logged. I think that message should probably be at WARN so that it shows > up in the admin UI logging tab with default settings. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13293) org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error consuming and closing http response stream.
[
https://issues.apache.org/jira/browse/SOLR-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816413#comment-16816413
]
Kevin Risden commented on SOLR-13293:
-
[~kstoney] - I saw you posted about prometheus as well. Is it possible these
are metrics related?
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> -
>
> Key: SOLR-13293
> URL: https://issues.apache.org/jira/browse/SOLR-13293
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 8.0
>Reporter: Karl Stoney
>Priority: Minor
>
> Hi,
> Testing out branch_8x, we're randomly seeing the following errors on a simple
> 3 node cluster. It doesn't appear to affect replication (the cluster remains
> green).
> They come in (mass, literally 1000s at a time) bulk.
> There we no network issues at the time.
> {code:java}
> 16:53:01.492 [updateExecutor-4-thread-34-processing-x:at-uk_shard1_replica_n1
> r:core_node3 null n:solr-2.search-solr.preprod.k8.atcloud.io:80_solr c:at-uk
> s:shard1] ERROR
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> java.nio.channels.AsynchronousCloseException: null
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:316)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at java.io.InputStream.read(InputStream.java:101) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:287)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:283)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root
> - 2019-03-04 16:30:04]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04
> 16:30:04]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04 16:30:04]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13293) org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error consuming and closing http response stream.
[
https://issues.apache.org/jira/browse/SOLR-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816490#comment-16816490
]
Kevin Risden edited comment on SOLR-13293 at 4/12/19 5:13 PM:
--
No I understand the root cause is different - I meant more are these bulk HTTP
requests from metrics somehow? Like if metrics are disabled do these errors go
away.
was (Author: risdenk):
No I understand the root cause is different - I meant more are these bulk HTTP
requests from metrics somehow?
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> -
>
> Key: SOLR-13293
> URL: https://issues.apache.org/jira/browse/SOLR-13293
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 8.0
>Reporter: Karl Stoney
>Priority: Minor
>
> Hi,
> Testing out branch_8x, we're randomly seeing the following errors on a simple
> 3 node cluster. It doesn't appear to affect replication (the cluster remains
> green).
> They come in (mass, literally 1000s at a time) bulk.
> There we no network issues at the time.
> {code:java}
> 16:53:01.492 [updateExecutor-4-thread-34-processing-x:at-uk_shard1_replica_n1
> r:core_node3 null n:solr-2.search-solr.preprod.k8.atcloud.io:80_solr c:at-uk
> s:shard1] ERROR
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> java.nio.channels.AsynchronousCloseException: null
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:316)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at java.io.InputStream.read(InputStream.java:101) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:287)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:283)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root
> - 2019-03-04 16:30:04]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04
> 16:30:04]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04 16:30:04]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13293) org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error consuming and closing http response stream.
[
https://issues.apache.org/jira/browse/SOLR-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816490#comment-16816490
]
Kevin Risden commented on SOLR-13293:
-
No I understand the root cause is different - I meant more are these bulk HTTP
requests from metrics somehow?
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> -
>
> Key: SOLR-13293
> URL: https://issues.apache.org/jira/browse/SOLR-13293
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 8.0
>Reporter: Karl Stoney
>Priority: Minor
>
> Hi,
> Testing out branch_8x, we're randomly seeing the following errors on a simple
> 3 node cluster. It doesn't appear to affect replication (the cluster remains
> green).
> They come in (mass, literally 1000s at a time) bulk.
> There we no network issues at the time.
> {code:java}
> 16:53:01.492 [updateExecutor-4-thread-34-processing-x:at-uk_shard1_replica_n1
> r:core_node3 null n:solr-2.search-solr.preprod.k8.atcloud.io:80_solr c:at-uk
> s:shard1] ERROR
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> java.nio.channels.AsynchronousCloseException: null
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:316)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at java.io.InputStream.read(InputStream.java:101) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:287)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:283)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root
> - 2019-03-04 16:30:04]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04
> 16:30:04]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04 16:30:04]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13293) org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error consuming and closing http response stream.
[
https://issues.apache.org/jira/browse/SOLR-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816499#comment-16816499
]
Kevin Risden commented on SOLR-13293:
-
Ah sorry I missed the "ConcurrentUpdate" part. I saw "metrics-core" and thought
eh maybe related to metrics. Sorry don't have any other ideas right now.
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> -
>
> Key: SOLR-13293
> URL: https://issues.apache.org/jira/browse/SOLR-13293
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 8.0
>Reporter: Karl Stoney
>Priority: Minor
>
> Hi,
> Testing out branch_8x, we're randomly seeing the following errors on a simple
> 3 node cluster. It doesn't appear to affect replication (the cluster remains
> green).
> They come in (mass, literally 1000s at a time) bulk.
> There we no network issues at the time.
> {code:java}
> 16:53:01.492 [updateExecutor-4-thread-34-processing-x:at-uk_shard1_replica_n1
> r:core_node3 null n:solr-2.search-solr.preprod.k8.atcloud.io:80_solr c:at-uk
> s:shard1] ERROR
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient - Error
> consuming and closing http response stream.
> java.nio.channels.AsynchronousCloseException: null
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:316)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at java.io.InputStream.read(InputStream.java:101) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.client.util.InputStreamResponseListener$Input.read(InputStreamResponseListener.java:287)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:283)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root
> - 2019-03-04 16:30:04]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04
> 16:30:04]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-8.1.0-SNAPSHOT.jar:8.1.0-SNAPSHOT
> b14748e61fd147ea572f6545265b883fa69ed27f - root - 2019-03-04 16:30:04]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13408) Cannot start/stop DaemonStream repeatedly
[
https://issues.apache.org/jira/browse/SOLR-13408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819011#comment-16819011
]
Kevin Risden commented on SOLR-13408:
-
I think even just calling open twice would cause an issue. There is nothing
stopping someone from opening the daemon stream programmatically twice.
> Cannot start/stop DaemonStream repeatedly
> -
>
> Key: SOLR-13408
> URL: https://issues.apache.org/jira/browse/SOLR-13408
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13408.patch
>
>
> If I create a DaemonStream then use the API commands to stop it then start it
> repeatedly, after the first time it's stopped/started, it cannot be stopped
> again.
> DaemonStream.close() checks whether a local variable "closed" is true, and if
> so does nothing. Otherwise it closes the stream then sets "closed" to true.
> However, when the stream is started again, "closed" is not set to false,
> therefore the next time you try to stop the deamon, nothing happens and it
> continues to run. One other consequence of this is that you can have orphan
> threads running in the background. Say I
> {code:java}
> stop the daemon
> start it again
> create another one with the same ID
> {code}
> When the new one is created, this code is executed over in
> StreamHandler.handleRequestBody:
> {code:java}
> daemons.remove(daemonStream.getId()).close();
> {code}
> which will not terminate the stream thread as above. Then the open() method
> executes this:
> {code:java}
> this.streamRunner = new StreamRunner(runInterval, id);
> {code}
> leaving the thread running.
> Finally, there's an NPE if I try to start a non-existent daemon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13408) Cannot start/stop DaemonStream repeatedly
[
https://issues.apache.org/jira/browse/SOLR-13408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819013#comment-16819013
]
Kevin Risden commented on SOLR-13408:
-
StreamExpressionTest is where some existing daemon open/close tests are.
> Cannot start/stop DaemonStream repeatedly
> -
>
> Key: SOLR-13408
> URL: https://issues.apache.org/jira/browse/SOLR-13408
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13408.patch
>
>
> If I create a DaemonStream then use the API commands to stop it then start it
> repeatedly, after the first time it's stopped/started, it cannot be stopped
> again.
> DaemonStream.close() checks whether a local variable "closed" is true, and if
> so does nothing. Otherwise it closes the stream then sets "closed" to true.
> However, when the stream is started again, "closed" is not set to false,
> therefore the next time you try to stop the deamon, nothing happens and it
> continues to run. One other consequence of this is that you can have orphan
> threads running in the background. Say I
> {code:java}
> stop the daemon
> start it again
> create another one with the same ID
> {code}
> When the new one is created, this code is executed over in
> StreamHandler.handleRequestBody:
> {code:java}
> daemons.remove(daemonStream.getId()).close();
> {code}
> which will not terminate the stream thread as above. Then the open() method
> executes this:
> {code:java}
> this.streamRunner = new StreamRunner(runInterval, id);
> {code}
> leaving the thread running.
> Finally, there's an NPE if I try to start a non-existent daemon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13726: Component/s: security > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: security, SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923533#comment-16923533 ] Kevin Risden commented on SOLR-13726: - NIFI-5148 handled this specifically for NiFi to avoid the JVM property change in Krb5HttpClientBuilder > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669562#comment-16669562
]
Kevin Risden commented on SOLR-12932:
-
Below did not reproduce the the reproduce line. Saved logs off in case more
details needed.
Test: TestCollectionsAPIViaSolrCloudCluster#testCollectionCreateSearchDelete
Fail message:
{noformat}
testCollectionCreateSearchDelete
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestCollectionsAPIViaSolrCloudCluster
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=69334EE3FF38A1CC
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=it-IT
-Dtests.timezone=Africa/Tunis -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 13.3s J7 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at http://127.0.0.1:33783/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([69334EE3FF38A1CC:CAC9E04678D04B69]:0)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
[junit4]>at
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:181)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:33783/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
[junit4]>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4]>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor.runWorker(Thr
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669568#comment-16669568
]
Kevin Risden commented on SOLR-12932:
-
Separate test run. Seed does not reproduce.
Test: OverseerTest#testBadQueueItem
Fail message:
{noformat}
23:37:34 [junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtests.method=testBadQueueItem
-Dtests.seed=34970C10FE2A115D -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=fr -Dtests.timezone=Canada/Yukon -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
23:37:34 [junit4] FAILURE 0.88s J6 | OverseerTest.testBadQueueItem <<<
23:37:34 [junit4] > Throwable #1: java.lang.AssertionError: expected:<1>
but was:<0>
23:37:34 [junit4] > at
__randomizedtesting.SeedInfo.seed([34970C10FE2A115D:843AC65BA75F47C5]:0)
23:37:34 [junit4] > at
org.apache.solr.cloud.OverseerTest.testBadQueueItem(OverseerTest.java:424)
23:37:34 [junit4] > at java.lang.Thread.run(Thread.java:748){noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669562#comment-16669562
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 3:46 AM:
---
Below did not reproduce the the reproduce line. Saved logs off in case more
details needed.
Test: TestCollectionsAPIViaSolrCloudCluster#testCollectionCreateSearchDelete
Fail message:
{noformat}
testCollectionCreateSearchDelete
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestCollectionsAPIViaSolrCloudCluster
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=69334EE3FF38A1CC
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=it-IT
-Dtests.timezone=Africa/Tunis -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 13.3s J7 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at http://127.0.0.1:33783/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([69334EE3FF38A1CC:CAC9E04678D04B69]:0)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
[junit4]>at
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:181)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:33783/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
[junit4]>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4]>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4]>at
j
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[ https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670004#comment-16670004 ] Kevin Risden commented on SOLR-12932: - I ran the tests overnight about ever 45min and have some more failures to share. I'll collect the test cases and error messages. > ant test (without badapples=false) should pass easily for developers. > - > > Key: SOLR-12932 > URL: https://issues.apache.org/jira/browse/SOLR-12932 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > If we fix the tests we will end up here anyway, but we can shortcut this. > Once I get my first patch in, anyone who mentions a test that fails locally > for them at any time (not jenkins), I will fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670058#comment-16670058
]
Kevin Risden commented on SOLR-12932:
-
Test: DistribCursorPagingTest
{noformat}
reproduce with: ant test -Dtestcase=DistribCursorPagingTest
-Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
.facet_counts.facet_fields.str.x:0!=null
23:47:46[junit4]> at
__randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
23:47:46[junit4]> at
java.lang.Thread.run(Thread.java:748){noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670058#comment-16670058
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 12:57 PM:
Test: DistribCursorPagingTest
{noformat}
reproduce with: ant test -Dtestcase=DistribCursorPagingTest
-Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
.facet_counts.facet_fields.str.x:0!=null
23:47:46[junit4]> at
__randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
23:47:46[junit4]> at
java.lang.Thread.run(Thread.java:748){noformat}
was (Author: risdenk):
Test: DistribCursorPagingTest
{noformat}
reproduce with: ant test -Dtestcase=DistribCursorPagingTest
-Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
.facet_counts.facet_fields.str.x:0!=null
23:47:46[junit4]> at
__randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
23:47:46[junit4]> at
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
23:47:46[junit4]> at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
23:47:46[junit4]> at
java.lang.Thread.run(Thread.java:748){noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubs
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670059#comment-16670059
]
Kevin Risden commented on SOLR-12932:
-
Test: TestPKIAuthenticationPlugin
{noformat}
reproduce with: ant test -Dtestcase=TestPKIAuthenticationPlugin
-Dtests.method=test -Dtests.seed=4FE78DD4E91611D9 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=Asia/Kabul
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 10.7s J0 | TestPKIAuthenticationPlugin.test <<<
[junit4] > Throwable #1: java.lang.NullPointerException
[junit4] > at
__randomizedtesting.SeedInfo.seed([4FE78DD4E91611D9:C7B3B20E47EA7C21]:0)
[junit4] > at
org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:105)
[junit4] > at java.lang.Thread.run(Thread.java:748){noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670060#comment-16670060
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 12:58 PM:
Test: AutoAddReplicasPlanActionTest
{code:java}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=76A7FA053BF740C5 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr -Dtests.timezone=Asia/Baku
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
00:46:11[junit4] ERROR 37.4s J5 |
AutoAddReplicasPlanActionTest.testSimple <<<
00:46:11[junit4]> Throwable #1: java.util.concurrent.TimeoutException
00:46:11[junit4]> at
__randomizedtesting.SeedInfo.seed([76A7FA053BF740C5:4E14DEFB1C049414]:0)
00:46:11[junit4]> at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:114)
00:46:11[junit4]> at java.lang.Thread.run(Thread.java:748){code}
was (Author: risdenk):
Test: AutoAddReplicasPlanActionTest
{noformat}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=76A7FA053BF740C5 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr -Dtests.timezone=Asia/Baku
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII 00:46:11 [junit4] ERROR
37.4s J5 | AutoAddReplicasPlanActionTest.testSimple <<< 00:46:11 [junit4] >
Throwable #1: java.util.concurrent.TimeoutException 00:46:11 [junit4] > at
__randomizedtesting.SeedInfo.seed([76A7FA053BF740C5:4E14DEFB1C049414]:0)
00:46:11 [junit4] > at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
00:46:11 [junit4] > at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
00:46:11 [junit4] > at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:114)
00:46:11 [junit4] > at java.lang.Thread.run(Thread.java:748)
{noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670060#comment-16670060
]
Kevin Risden commented on SOLR-12932:
-
Test: AutoAddReplicasPlanActionTest
{noformat}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=76A7FA053BF740C5 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr -Dtests.timezone=Asia/Baku
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII 00:46:11 [junit4] ERROR
37.4s J5 | AutoAddReplicasPlanActionTest.testSimple <<< 00:46:11 [junit4] >
Throwable #1: java.util.concurrent.TimeoutException 00:46:11 [junit4] > at
__randomizedtesting.SeedInfo.seed([76A7FA053BF740C5:4E14DEFB1C049414]:0)
00:46:11 [junit4] > at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
00:46:11 [junit4] > at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
00:46:11 [junit4] > at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:114)
00:46:11 [junit4] > at java.lang.Thread.run(Thread.java:748)
{noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670065#comment-16670065
]
Kevin Risden commented on SOLR-12932:
-
Test: TestCollectionsAPIViaSolrCloudCluster
{code:java}
reproduce with: ant test -Dtestcase=TestCollectionsAPIViaSolrCloudCluster
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=879612B1BD020602
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=fr-LU
-Dtests.timezone=Canada/Yukon -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
01:16:51[junit4] ERROR 8.48s J7 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
01:16:51[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at https://127.0.0.1:35461/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
01:16:51[junit4]>
01:16:51[junit4]> HTTP ERROR 404
01:16:51[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
01:16:51[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> at
__randomizedtesting.SeedInfo.seed([879612B1BD020602:246CBC143AEAECA7]:0)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
01:16:51[junit4]> at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
01:16:51[junit4]> at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
01:16:51[junit4]> at
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:181)
01:16:51[junit4]> at java.lang.Thread.run(Thread.java:748)
01:16:51[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at https://127.0.0.1:35461/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
01:16:51[junit4]>
01:16:51[junit4]> HTTP ERROR 404
01:16:51[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
01:16:51[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
01:16:51[junit4]> at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:16:51[junit4]> at
org.apache.solr.c
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670075#comment-16670075
]
Kevin Risden commented on SOLR-12932:
-
Test: ExecutePlanActionTest
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=C96AD1F563B86BE2 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-VE -Dtests.timezone=America/Ensenada
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 2.56s J0 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([C96AD1F563B86BE2:790BDFD94687CAC7]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670078#comment-16670078
]
Kevin Risden commented on SOLR-12932:
-
Test: SolrCoreTest#testReloadLeak
{code:java}
NOTE: reproduce with: ant test -Dtestcase=SolrCoreTest
-Dtests.method=testReloadLeak -Dtests.seed=153A4F27CDF7F30F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=vi-VN -Dtests.timezone=America/Denver
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 0.81s J3 | SolrCoreTest.testReloadLeak <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=18166, name=testReloadLeak-7844-thread-1,
state=RUNNABLE, group=TGRP-SolrCoreTest]
[junit4]>at
__randomizedtesting.SeedInfo.seed([153A4F27CDF7F30F:9792FAE9140ECF29]:0)
[junit4]> Caused by:
org.apache.solr.update.SolrCoreState$CoreIsClosedException
[junit4]>at
__randomizedtesting.SeedInfo.seed([153A4F27CDF7F30F]:0)
[junit4]>at
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2003)
[junit4]>at
org.apache.solr.core.SolrCoreTest$NewSearcherRunnable.run(SolrCoreTest.java:311)
[junit4]>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670059#comment-16670059
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 1:06 PM:
---
Test: TestPKIAuthenticationPlugin#test
{code:java}
reproduce with: ant test -Dtestcase=TestPKIAuthenticationPlugin
-Dtests.method=test -Dtests.seed=4FE78DD4E91611D9 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=Asia/Kabul
-Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] ERROR 10.7s J0 |
TestPKIAuthenticationPlugin.test <<< [junit4] > Throwable #1:
java.lang.NullPointerException [junit4] > at
__randomizedtesting.SeedInfo.seed([4FE78DD4E91611D9:C7B3B20E47EA7C21]:0)
[junit4] > at
org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:105)
[junit4] > at java.lang.Thread.run(Thread.java:748){code}
was (Author: risdenk):
Test: TestPKIAuthenticationPlugin
{noformat}
reproduce with: ant test -Dtestcase=TestPKIAuthenticationPlugin
-Dtests.method=test -Dtests.seed=4FE78DD4E91611D9 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=Asia/Kabul
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 10.7s J0 | TestPKIAuthenticationPlugin.test <<<
[junit4] > Throwable #1: java.lang.NullPointerException
[junit4] > at
__randomizedtesting.SeedInfo.seed([4FE78DD4E91611D9:C7B3B20E47EA7C21]:0)
[junit4] > at
org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:105)
[junit4] > at java.lang.Thread.run(Thread.java:748){noformat}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670065#comment-16670065
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 1:06 PM:
---
Test: TestCollectionsAPIViaSolrCloudCluster#testCollectionCreateSearchDelete
{code:java}
reproduce with: ant test -Dtestcase=TestCollectionsAPIViaSolrCloudCluster
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=879612B1BD020602
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=fr-LU
-Dtests.timezone=Canada/Yukon -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
01:16:51[junit4] ERROR 8.48s J7 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
01:16:51[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at https://127.0.0.1:35461/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
01:16:51[junit4]>
01:16:51[junit4]> HTTP ERROR 404
01:16:51[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
01:16:51[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> at
__randomizedtesting.SeedInfo.seed([879612B1BD020602:246CBC143AEAECA7]:0)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
01:16:51[junit4]> at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
01:16:51[junit4]> at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
01:16:51[junit4]> at
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:181)
01:16:51[junit4]> at java.lang.Thread.run(Thread.java:748)
01:16:51[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at https://127.0.0.1:35461/solr/testcollection_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html.
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n2/update
01:16:51[junit4]>
01:16:51[junit4]> HTTP ERROR 404
01:16:51[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n2/update. Reason:
01:16:51[junit4]> Can not find:
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
01:16:51[junit4]>
01:16:51[junit4]>
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
01:16:51[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
01:16:51[junit4]> at
java.util.concurrent.Futur
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670075#comment-16670075
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 1:06 PM:
---
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=C96AD1F563B86BE2 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-VE -Dtests.timezone=America/Ensenada
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 2.56s J0 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([C96AD1F563B86BE2:790BDFD94687CAC7]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
was (Author: risdenk):
Test: ExecutePlanActionTest
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=C96AD1F563B86BE2 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-VE -Dtests.timezone=America/Ensenada
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 2.56s J0 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([C96AD1F563B86BE2:790BDFD94687CAC7]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670060#comment-16670060
]
Kevin Risden edited comment on SOLR-12932 at 10/31/18 1:06 PM:
---
Test: AutoAddReplicasPlanActionTest#testSimple
{code:java}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=76A7FA053BF740C5 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr -Dtests.timezone=Asia/Baku
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
00:46:11[junit4] ERROR 37.4s J5 |
AutoAddReplicasPlanActionTest.testSimple <<<
00:46:11[junit4]> Throwable #1: java.util.concurrent.TimeoutException
00:46:11[junit4]> at
__randomizedtesting.SeedInfo.seed([76A7FA053BF740C5:4E14DEFB1C049414]:0)
00:46:11[junit4]> at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:114)
00:46:11[junit4]> at java.lang.Thread.run(Thread.java:748){code}
was (Author: risdenk):
Test: AutoAddReplicasPlanActionTest
{code:java}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=76A7FA053BF740C5 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr -Dtests.timezone=Asia/Baku
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
00:46:11[junit4] ERROR 37.4s J5 |
AutoAddReplicasPlanActionTest.testSimple <<<
00:46:11[junit4]> Throwable #1: java.util.concurrent.TimeoutException
00:46:11[junit4]> at
__randomizedtesting.SeedInfo.seed([76A7FA053BF740C5:4E14DEFB1C049414]:0)
00:46:11[junit4]> at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
00:46:11[junit4]> at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:114)
00:46:11[junit4]> at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670086#comment-16670086
]
Kevin Risden commented on SOLR-12932:
-
All of the ones I posted above are single failures in a test run. Here is a run
with 3 failures:
Test: TestCloudSearcherWarming#testRepFactor1LeaderStartup
{code:java}
reproduce with: ant test -Dtestcase=TestCloudSearcherWarming
-Dtests.method=testRepFactor1LeaderStartup -Dtests.seed=E30A144FF13D52E7
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-SA
-Dtests.timezone=NZ-CHAT -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 33.4s J0 |
TestCloudSearcherWarming.testRepFactor1LeaderStartup <<<
[junit4]> Throwable #1: java.lang.AssertionError: jetty count:0
[junit4]> null
[junit4]> Live Nodes: [127.0.0.1:44315_solr]
[junit4]> Last available state:
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
[junit4]> "pullReplicas":"0",
[junit4]> "replicationFactor":"1",
[junit4]> "shards":{"shard1":{
[junit4]> "range":"8000-7fff",
[junit4]> "state":"active",
[junit4]> "replicas":{"core_node2":{
[junit4]>
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",
[junit4]> "base_url":"http://127.0.0.1:44315/solr";,
[junit4]> "node_name":"127.0.0.1:44315_solr",
[junit4]> "state":"active",
[junit4]> "type":"NRT",
[junit4]> "force_set_state":"false",
[junit4]> "leader":"true",
[junit4]> "router":{"name":"compositeId"},
[junit4]> "maxShardsPerNode":"1",
[junit4]> "autoAddReplicas":"false",
[junit4]> "nrtReplicas":"1",
[junit4]> "tlogReplicas":"0"}
[junit4]>at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:283)
[junit4]>at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:261)
[junit4]>at
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:117)
[junit4]>at java.lang.Thread.run(Thread.java:748)Throwable #2:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available
to handle this request
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:461)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
[junit4]>at
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:508)
[junit4]>at
org.apache.solr.cloud.TestCloudSearcherWarming.tearDown(TestCloudSearcherWarming.java:78)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Test: NodeLostTriggerTest#testListenerAcceptance
{code:java}
NOTE: reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=E30A144FF13D52E7
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=fr-CH
-Dtests.timezone=ART -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.20s J0 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([E30A144FF13D52E7:F2BE4EA848B44611]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Test: NodeLostTriggerTest#testTrigger
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testTrigger -Dtests.seed=E30A144FF13D52E7 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=fr-CH -Dtests.timezone=ART
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 2.04s J0 | NodeLostTriggerTest.testTrigger <<<
[junit4]> Throwable #1: java.lang.AssertionError: [127.0.0.1:40385_solr]
doesn't contain 127.0.0.1:45145_solr
[junit4]>at
__randomizedtesting.SeedInfo.seed([E30A144FF13D52E7:80C122CD68F221CA]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testTrigger(NodeLostTriggerTest.java:117)
[junit4]
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670159#comment-16670159
]
Kevin Risden commented on SOLR-12932:
-
Test:TestAuthenticationFramework#testBasics
{code:java}
reproduce with: ant test -Dtestcase=TestAuthenticationFramework
-Dtests.method=testBasics -Dtests.seed=D3D81D8F48AFF8C -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=de-LU -Dtests.timezone=PRT
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
09:52:10[junit4] ERROR 7.23s J0 | TestAuthenticationFramework.testBasics
<<<
09:52:10[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at https://127.0.0.1:39937/solr/testcollection_shard1_replica_n3:
Expected mime type application/octet-stream but got text/html.
09:52:10[junit4]>
09:52:10[junit4]>
09:52:10[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n3/update
09:52:10[junit4]>
09:52:10[junit4]> HTTP ERROR 404
09:52:10[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n3/update. Reason:
09:52:10[junit4]> Can not find:
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
09:52:10[junit4]>
09:52:10[junit4]>
09:52:10[junit4]> at
__randomizedtesting.SeedInfo.seed([D3D81D8F48AFF8C:30E52FF4CC64A1FC]:0)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
09:52:10[junit4]> at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
09:52:10[junit4]> at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
09:52:10[junit4]> at
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:128)
09:52:10[junit4]> at
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:75)
09:52:10[junit4]> at java.lang.Thread.run(Thread.java:748)
09:52:10[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at https://127.0.0.1:39937/solr/testcollection_shard1_replica_n3:
Expected mime type application/octet-stream but got text/html.
09:52:10[junit4]>
09:52:10[junit4]>
09:52:10[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n3/update
09:52:10[junit4]>
09:52:10[junit4]> HTTP ERROR 404
09:52:10[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n3/update. Reason:
09:52:10[junit4]> Can not find:
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
09:52:10[junit4]>
09:52:10[junit4]>
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
09:52:10[junit4]> at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
09:52:10[junit4]> at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
09:52:10[junit4]> at
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[ https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670180#comment-16670180 ] Kevin Risden commented on SOLR-12932: - I checked all the reproduce with lines and was not able to reproduce the failures for the failures I posted. For the record I've run 20 runs and 5 have succeeded. I didn't post all the failures since many were the same. I'll keep running the tests to see if anything else falls out. > ant test (without badapples=false) should pass easily for developers. > - > > Key: SOLR-12932 > URL: https://issues.apache.org/jira/browse/SOLR-12932 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > If we fix the tests we will end up here anyway, but we can shortcut this. > Once I get my first patch in, anyone who mentions a test that fails locally > for them at any time (not jenkins), I will fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12946) DistribCursorPagingTest non-reproducible failures in comparing facet counts
[
https://issues.apache.org/jira/browse/SOLR-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-12946:
Attachment: risdenk-nuc-20181031-build-31.txt.gz
risdenk-nuc-20181031-build-11.txt.gz
> DistribCursorPagingTest non-reproducible failures in comparing facet counts
> ---
>
> Key: SOLR-12946
> URL: https://issues.apache.org/jira/browse/SOLR-12946
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: risdenk-nuc-20181031-build-11.txt.gz,
> risdenk-nuc-20181031-build-31.txt.gz
>
>
> Anecdotal reports of failures from DistribCursorPagingTest long the lines of..
> {noformat}
> reproduce with: ant test -Dtestcase=DistribCursorPagingTest
> -Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> 23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
> 23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> .facet_counts.facet_fields.str.x:0!=null
> 23:47:46[junit4]> at
> __randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
> 23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
> 23:47:46[junit4]> at
> java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12946) DistribCursorPagingTest non-reproducible failures in comparing facet counts
[
https://issues.apache.org/jira/browse/SOLR-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670457#comment-16670457
]
Kevin Risden commented on SOLR-12946:
-
[~hossman] - Attached full logs from two test failures. For reference here is
some build information:
* Intel Nuc 8th gen i5 32 GB RAM 512GB SSD
* Builds on docker clean workspace each time
* No other CPU/memory/disk intensive jobs at the same time
* build-11 had jvms=8
* build-31 had jvms=4
> DistribCursorPagingTest non-reproducible failures in comparing facet counts
> ---
>
> Key: SOLR-12946
> URL: https://issues.apache.org/jira/browse/SOLR-12946
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: risdenk-nuc-20181031-build-11.txt.gz,
> risdenk-nuc-20181031-build-31.txt.gz
>
>
> Anecdotal reports of failures from DistribCursorPagingTest long the lines of..
> {noformat}
> reproduce with: ant test -Dtestcase=DistribCursorPagingTest
> -Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> 23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
> 23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> .facet_counts.facet_fields.str.x:0!=null
> 23:47:46[junit4]> at
> __randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
> 23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
> 23:47:46[junit4]> at
> java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12946) DistribCursorPagingTest non-reproducible failures in comparing facet counts
[
https://issues.apache.org/jira/browse/SOLR-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670475#comment-16670475
]
Kevin Risden commented on SOLR-12946:
-
build-11 and build-31 were both from
[https://github.com/apache/lucene-solr/pull/486/commits/0934d88f2cb5eee10ee319d94332fdc1300939a4]
at that specific commit.
> DistribCursorPagingTest non-reproducible failures in comparing facet counts
> ---
>
> Key: SOLR-12946
> URL: https://issues.apache.org/jira/browse/SOLR-12946
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: risdenk-nuc-20181031-build-11.txt.gz,
> risdenk-nuc-20181031-build-31.txt.gz
>
>
> Anecdotal reports of failures from DistribCursorPagingTest long the lines of..
> {noformat}
> reproduce with: ant test -Dtestcase=DistribCursorPagingTest
> -Dtests.method=test -Dtests.seed=87B400F0180614A3 -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=sq-AL -Dtests.timezone=Etc/GMT+9
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> 23:47:46[junit4] FAILURE 19.4s J7 | DistribCursorPagingTest.test <<<
> 23:47:46[junit4]> Throwable #1: junit.framework.AssertionFailedError:
> .facet_counts.facet_fields.str.x:0!=null
> 23:47:46[junit4]> at
> __randomizedtesting.SeedInfo.seed([87B400F0180614A3:FE03F2AB6FA795B]:0)
> 23:47:46[junit4]> at junit.framework.Assert.fail(Assert.java:50)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:985)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1012)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:666)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:629)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:258)
> 23:47:46[junit4]> at
> org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:90)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1066)
> 23:47:46[junit4]> at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1040)
> 23:47:46[junit4]> at
> java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670542#comment-16670542
]
Kevin Risden commented on SOLR-12932:
-
Adding the commit hash since I know you are updating the PR. First failure out
of 3 builds on the new commit so far :)
Commit: 88c37601f01c6fe5e508073f57dd2508ebed9a4b
Test: AutoAddReplicasPlanActionTest#testSimple
{code:java}
reproduce with: ant test -Dtestcase=AutoAddReplicasPlanActionTest
-Dtests.method=testSimple -Dtests.seed=ED45ACA1F83399DB -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ga -Dtests.timezone=Canada/Pacific
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] ERROR 57.2s J5 | AutoAddReplicasPlanActionTest.testSimple <<<
[junit4]> Throwable #1: java.util.concurrent.TimeoutException
[junit4]>at
__randomizedtesting.SeedInfo.seed([ED45ACA1F83399DB:D5F6885FDFC04D0A]:0)
[junit4]>at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
[junit4]>at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.waitForNodeLeave(AutoAddReplicasPlanActionTest.java:188)
[junit4]>at
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple(AutoAddReplicasPlanActionTest.java:181)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670597#comment-16670597
]
Kevin Risden commented on SOLR-12932:
-
Commit: 88c37601f01c6fe5e508073f57dd2508ebed9a4b
Test: OverseerTest#testDoubleAssignment
{code:java}
reproduce with: ant test -Dtestcase=OverseerTest
-Dtests.method=testDoubleAssignment -Dtests.seed=9E1068EDAF5AF7A5
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-PA
-Dtests.timezone=Pacific/Ponape -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 17.7s J3 | OverseerTest.testDoubleAssignment <<<
[junit4]> Throwable #1: java.util.concurrent.TimeoutException
[junit4]>at
__randomizedtesting.SeedInfo.seed([9E1068EDAF5AF7A5:DE553B06E407E2F3]:0)
[junit4]>at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1512)
[junit4]>at
org.apache.solr.cloud.OverseerTest.testDoubleAssignment(OverseerTest.java:987)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670640#comment-16670640
]
Kevin Risden commented on SOLR-12932:
-
Commit: 88c37601f01c6fe5e508073f57dd2508ebed9a4b
Test:TestCollectionsAPIViaSolrCloudCluster#testCollectionCreateSearchDelete
{code:java}
reproduce with: ant test -Dtestcase=TestCollectionsAPIViaSolrCloudCluster
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=91B211642503876A
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ga
-Dtests.timezone=Africa/Kinshasa -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 9.16s J3 |
TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
[junit4]> Throwable #1:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from
server at http://127.0.0.1:42289/solr/testcollection_shard1_replica_n3:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n3/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n3/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([91B211642503876A:3248BFC1A2EB6DCF]:0)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
[junit4]>at
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:181)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]> Caused by:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:42289/solr/testcollection_shard1_replica_n3:
Expected mime type application/octet-stream but got text/html.
[junit4]>
[junit4]>
[junit4]> Error 404 Can not find:
/solr/testcollection_shard1_replica_n3/update
[junit4]>
[junit4]> HTTP ERROR 404
[junit4]> Problem accessing
/solr/testcollection_shard1_replica_n3/update. Reason:
[junit4]> Can not find:
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.11.v20180605
[junit4]>
[junit4]>
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
[junit4]>at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:484)
[junit4]>at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:528)
[junit4]>at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4]>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPo
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670922#comment-16670922
]
Kevin Risden commented on SOLR-12932:
-
Different kind of failure since there was a stall.
Commit: 88c37601f01c6fe5e508073f57dd2508ebed9a4b
Test: TestSimTriggerIntegration#testListeners
{code:java}
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:38:04, stalled
for 1327s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:39:04, stalled
for 1387s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:40:04, stalled
for 1447s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:41:04, stalled
for 1507s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:42:04, stalled
for 1567s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:43:04, stalled
for 1627s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:44:04, stalled
for 1687s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:45:04, stalled
for 1747s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:46:04, stalled
for 1807s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:47:04, stalled
for 1867s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:48:04, stalled
for 1927s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:49:04, stalled
for 1987s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:50:04, stalled
for 2047s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:51:04, stalled
for 2107s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:52:04, stalled
for 2167s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:53:04, stalled
for 2227s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:54:04, stalled
for 2287s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:55:04, stalled
for 2347s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:56:04, stalled
for 2407s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:57:04, stalled
for 2467s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:58:04, stalled
for 2527s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T22:59:04, stalled
for 2587s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:00:04, stalled
for 2647s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:01:04, stalled
for 2707s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:02:04, stalled
for 2767s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:03:04, stalled
for 2827s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:04:04, stalled
for 2887s at: TestSimTriggerIntegration.testListeners
[junit4] HEARTBEAT J2 PID(480@f7bc5a140d51): 2018-10-31T23:05:04, stalled
for 2947s at: TestSimTriggerIntegration.testListeners
Build timed out (after 55 minutes). Marking the build as failed.
{code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670981#comment-16670981
]
Kevin Risden commented on SOLR-12932:
-
New commit hash failure but looks like there is already a commit to handle
this. New commit should get picked up in next test run.
Commit: 7fcd15843fed53ba7ce7ba8c2f1bf0d030d272f8
Test: NodeMarkersRegistrationTest#testNodeMarkersRegistration
{code:java}
reproduce with: ant test -Dtestcase=NodeMarkersRegistrationTest
-Dtests.method=testNodeMarkersRegistration -Dtests.seed=E9977750024DB50B
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-MX
-Dtests.timezone=Pacific/Ponape -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.25s J2 |
NodeMarkersRegistrationTest.testNodeMarkersRegistration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([E9977750024DB50B:F12DFF5C0C7878E4]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeMarkersRegistrationTest.testNodeMarkersRegistration(NodeMarkersRegistrationTest.java:113)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670981#comment-16670981
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 1:03 AM:
--
New commit hash failure but looks like there is already a commit to handle this
that wasn't in this run. New commit should get picked up in next test run.
Commit: 7fcd15843fed53ba7ce7ba8c2f1bf0d030d272f8
Test: NodeMarkersRegistrationTest#testNodeMarkersRegistration
{code:java}
reproduce with: ant test -Dtestcase=NodeMarkersRegistrationTest
-Dtests.method=testNodeMarkersRegistration -Dtests.seed=E9977750024DB50B
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-MX
-Dtests.timezone=Pacific/Ponape -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.25s J2 |
NodeMarkersRegistrationTest.testNodeMarkersRegistration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([E9977750024DB50B:F12DFF5C0C7878E4]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeMarkersRegistrationTest.testNodeMarkersRegistration(NodeMarkersRegistrationTest.java:113)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
was (Author: risdenk):
New commit hash failure but looks like there is already a commit to handle
this. New commit should get picked up in next test run.
Commit: 7fcd15843fed53ba7ce7ba8c2f1bf0d030d272f8
Test: NodeMarkersRegistrationTest#testNodeMarkersRegistration
{code:java}
reproduce with: ant test -Dtestcase=NodeMarkersRegistrationTest
-Dtests.method=testNodeMarkersRegistration -Dtests.seed=E9977750024DB50B
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-MX
-Dtests.timezone=Pacific/Ponape -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.25s J2 |
NodeMarkersRegistrationTest.testNodeMarkersRegistration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([E9977750024DB50B:F12DFF5C0C7878E4]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeMarkersRegistrationTest.testNodeMarkersRegistration(NodeMarkersRegistrationTest.java:113)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[ https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671581#comment-16671581 ] Kevin Risden commented on SOLR-12932: - Only 3 failures in the last 10 runs on commit 8e0733bc99544da01e9e115c1b28a2a7b9c380d4. Two failures are the same type. > ant test (without badapples=false) should pass easily for developers. > - > > Key: SOLR-12932 > URL: https://issues.apache.org/jira/browse/SOLR-12932 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > If we fix the tests we will end up here anyway, but we can shortcut this. > Once I get my first patch in, anyone who mentions a test that fails locally > for them at any time (not jenkins), I will fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671584#comment-16671584
]
Kevin Risden commented on SOLR-12932:
-
Two related failures on this run
Commit: 8e0733bc99544da01e9e115c1b28a2a7b9c380d4
Test: ChaosMonkeyNothingIsSafeTest#test
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.method=test -Dtests.seed=8A09DAB62DBF4345 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-MX -Dtests.timezone=Europe/London
-Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 34.7s J0 |
ChaosMonkeyNothingIsSafeTest.test <<< [junit4] > Throwable #1:
java.lang.AssertionError: document count mismatch. control=1560 sum(shards)=750
cloudClient=750 [junit4] > at
__randomizedtesting.SeedInfo.seed([8A09DAB62DBF4345:25DE56C83432EBD]:0)
[junit4] > at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1396)
[junit4] > at
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4] > at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.seed=8A09DAB62DBF4345 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=es-MX -Dtests.timezone=Europe/London -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ChaosMonkeyNothingIsSafeTest (suite) <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 8 threads leaked from SUITE
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest:
[junit4]>1) Thread[id=6981, name=zkCallback-1984-thread-4,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>2) Thread[id=6885, name=zkCallback-1984-thread-2,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>3) Thread[id=6792,
name=zkConnectionManagerCallback-1985-thread-1, state=WAITING,
group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
[junit4]> at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Threa
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671586#comment-16671586
]
Kevin Risden commented on SOLR-12932:
-
Commit: 8e0733bc99544da01e9e115c1b28a2a7b9c380d4
Test: AutoAddReplicasIntegrationTest#testSimple
{code:java}
NOTE: reproduce with: ant test -Dtestcase=AutoAddReplicasIntegrationTest
-Dtests.method=testSimple -Dtests.seed=E73476C72BD62F1 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=zh-HK -Dtests.timezone=Australia/Hobart
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 68.1s J3 | AutoAddReplicasIntegrationTest.testSimple <<<
[junit4]> Throwable #1: java.lang.AssertionError: Waiting for collection
testSimple2
[junit4]> null
[junit4]> Live Nodes: [127.0.0.1:35447_solr, 127.0.0.1:43523_solr]
[junit4]> Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/29)={
[junit4]> "pullReplicas":"0",
[junit4]> "replicationFactor":"2",
[junit4]> "shards":{
[junit4]> "shard1":{
[junit4]> "range":"8000-",
[junit4]> "state":"active",
[junit4]> "replicas":{
[junit4]> "core_node3":{
[junit4]> "core":"testSimple2_shard1_replica_n1",
[junit4]> "base_url":"http://127.0.0.1:43235/solr";,
[junit4]> "node_name":"127.0.0.1:43235_solr",
[junit4]> "state":"down",
[junit4]> "type":"NRT",
[junit4]> "force_set_state":"false"},
[junit4]> "core_node5":{
[junit4]> "core":"testSimple2_shard1_replica_n2",
[junit4]> "base_url":"http://127.0.0.1:35447/solr";,
[junit4]> "node_name":"127.0.0.1:35447_solr",
[junit4]> "state":"active",
[junit4]> "type":"NRT",
[junit4]> "force_set_state":"false",
[junit4]> "leader":"true"},
[junit4]> "core_node12":{
[junit4]> "core":"testSimple2_shard1_replica_n11",
[junit4]> "base_url":"http://127.0.0.1:35447/solr";,
[junit4]> "state":"down",
[junit4]> "node_name":"127.0.0.1:35447_solr",
[junit4]> "type":"NRT"}}},
[junit4]> "shard2":{
[junit4]> "range":"0-7fff",
[junit4]> "state":"active",
[junit4]> "replicas":{
[junit4]> "core_node8":{
[junit4]> "core":"testSimple2_shard2_replica_n6",
[junit4]> "base_url":"http://127.0.0.1:35447/solr";,
[junit4]> "node_name":"127.0.0.1:35447_solr",
[junit4]> "state":"active",
[junit4]> "type":"NRT",
[junit4]> "force_set_state":"false",
[junit4]> "leader":"true"},
[junit4]> "core_node10":{
[junit4]> "core":"testSimple2_shard2_replica_n9",
[junit4]> "base_url":"http://127.0.0.1:35447/solr";,
[junit4]> "node_name":"127.0.0.1:35447_solr",
[junit4]> "state":"active",
[junit4]> "type":"NRT",
[junit4]> "force_set_state":"false",
[junit4]> "router":{"name":"compositeId"},
[junit4]> "maxShardsPerNode":"2",
[junit4]> "autoAddReplicas":"true",
[junit4]> "nrtReplicas":"2",
[junit4]> "tlogReplicas":"0"}
[junit4]>at
__randomizedtesting.SeedInfo.seed([E73476C72BD62F1:36C06392554EB620]:0)
[junit4]>at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:283)
[junit4]>at
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:136)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
Reference: risdenk/nuc#57
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mai
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671584#comment-16671584
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 1:00 PM:
--
Two related failures on this run
Commit: 8e0733bc99544da01e9e115c1b28a2a7b9c380d4
Test: ChaosMonkeyNothingIsSafeTest#test
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.method=test -Dtests.seed=8A09DAB62DBF4345 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=es-MX -Dtests.timezone=Europe/London
-Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 34.7s J0 |
ChaosMonkeyNothingIsSafeTest.test <<< [junit4] > Throwable #1:
java.lang.AssertionError: document count mismatch. control=1560 sum(shards)=750
cloudClient=750 [junit4] > at
__randomizedtesting.SeedInfo.seed([8A09DAB62DBF4345:25DE56C83432EBD]:0)
[junit4] > at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1396)
[junit4] > at
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4] > at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.seed=8A09DAB62DBF4345 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=es-MX -Dtests.timezone=Europe/London -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.00s J0 | ChaosMonkeyNothingIsSafeTest (suite) <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 8 threads leaked from SUITE
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest:
[junit4]>1) Thread[id=6981, name=zkCallback-1984-thread-4,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>2) Thread[id=6885, name=zkCallback-1984-thread-2,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>3) Thread[id=6792,
name=zkConnectionManagerCallback-1985-thread-1, state=WAITING,
group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
[junit4]> at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671588#comment-16671588
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 1:01 PM:
--
Two failures related again.
Commit: 8e0733bc99544da01e9e115c1b28a2a7b9c380d4
Test: ChaosMonkeyNothingIsSafeTest#test
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.method=test -Dtests.seed=CD85E598152C3D2F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=US/Aleutian
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 26.9s J0 | ChaosMonkeyNothingIsSafeTest.test <<<
[junit4]> Throwable #1: java.lang.AssertionError: document count
mismatch. control=1886 sum(shards)=943 cloudClient=943
[junit4]>at
__randomizedtesting.SeedInfo.seed([CD85E598152C3D2F:45D1DA42BBD050D7]:0)
[junit4]>at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1396)
[junit4]>at
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.seed=CD85E598152C3D2F -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-BH -Dtests.timezone=US/Aleutian -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.00s J0 | ChaosMonkeyNothingIsSafeTest (suite) <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 9 threads leaked from SUITE
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest:
[junit4]>1) Thread[id=10235, name=zkCallback-2682-thread-4,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>2) Thread[id=10230, name=zkCallback-2682-thread-3,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>3) Thread[id=10066,
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[CD85E598152C3D2F]-EventThread,
state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
[junit4]> at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
[junit4]> at
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
[junit4]>4) Thread[id=10065,
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[CD85E598152C3D2
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671588#comment-16671588
]
Kevin Risden commented on SOLR-12932:
-
Two failures related again.
Commit: 8e0733bc99544da01e9e115c1b28a2a7b9c380d4
Test: ChaosMonkeyNothingIsSafeTest#test
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.method=test -Dtests.seed=CD85E598152C3D2F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=US/Aleutian
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 26.9s J0 | ChaosMonkeyNothingIsSafeTest.test <<<
[junit4]> Throwable #1: java.lang.AssertionError: document count
mismatch. control=1886 sum(shards)=943 cloudClient=943
[junit4]>at
__randomizedtesting.SeedInfo.seed([CD85E598152C3D2F:45D1DA42BBD050D7]:0)
[junit4]>at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1396)
[junit4]>at
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest
-Dtests.seed=CD85E598152C3D2F -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-BH -Dtests.timezone=US/Aleutian -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.00s J0 | ChaosMonkeyNothingIsSafeTest (suite) <<<
[junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.ThreadLeakError: 9 threads leaked from SUITE
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest:
[junit4]>1) Thread[id=10235, name=zkCallback-2682-thread-4,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>2) Thread[id=10230, name=zkCallback-2682-thread-3,
state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
[junit4]> at
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
[junit4]> at
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
[junit4]> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]> at java.lang.Thread.run(Thread.java:748)
[junit4]>3) Thread[id=10066,
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[CD85E598152C3D2F]-EventThread,
state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest]
[junit4]> at sun.misc.Unsafe.park(Native Method)
[junit4]> at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
[junit4]> at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
[junit4]> at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
[junit4]> at
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
[junit4]>4) Thread[id=10065,
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[CD85E598152C3D2F]-SendThread(127.0.0.1:45103),
state=TIMED_W
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671673#comment-16671673
]
Kevin Risden commented on SOLR-12932:
-
[~erickerickson] this is how I setup my local jenkins to run it. Workspace is
cleared since this is executed on transient docker containers. ivysettings.xml
is just to use my local maven cache.
{code:java}
git init /home/jenkins/agent/workspace/apache-solr-markmiller-test
git config remote.origin.url https://github.com/apache/lucene-solr
git fetch --no-tags origin pull/486/head:pr-486
git checkout pr-486
git rev-parse HEAD
ant ivy-bootstrap -Divysettings.xml=/home/jenkins/.ivy2/ivysettings.xml
cd solr
ant test -Divysettings.xml=/home/jenkins/.ivy2/ivysettings.xml
{code}
This sets up git in a folder, fetches the pr branch, checks it out, prints the
hash (so I can see which commit it was against later), run ivy-bootstrap, cd
solr, and run ant test.
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[ https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672279#comment-16672279 ] Kevin Risden commented on SOLR-12932: - So there have been two failures in the last 15 runs. I know there have been commits to the PR so posting the two failures with commits that they were run against. > ant test (without badapples=false) should pass easily for developers. > - > > Key: SOLR-12932 > URL: https://issues.apache.org/jira/browse/SOLR-12932 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > If we fix the tests we will end up here anyway, but we can shortcut this. > Once I get my first patch in, anyone who mentions a test that fails locally > for them at any time (not jenkins), I will fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672282#comment-16672282
]
Kevin Risden commented on SOLR-12932:
-
Two failures associated with this run.
Commit: a092f1a79edbf0092f96155414215b443363c2fb
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=DBF7318E39CB980F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=he-IL -Dtests.timezone=Africa/Juba
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 2.92s J3 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:6B963FA21CF4392A]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=DBF7318E39CB980F
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.31s J1 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:CA436B6980428CF9]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#65
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672282#comment-16672282
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 10:01 PM:
---
Two failures associated with this run.
Commit: a092f1a79edbf0092f96155414215b443363c2fb
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=DBF7318E39CB980F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=he-IL -Dtests.timezone=Africa/Juba
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 2.92s J3 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:6B963FA21CF4392A]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748) {code}
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=DBF7318E39CB980F
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.31s J1 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:CA436B6980428CF9]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#65
was (Author: risdenk):
Two failures associated with this run.
Commit: a092f1a79edbf0092f96155414215b443363c2fb
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=DBF7318E39CB980F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=he-IL -Dtests.timezone=Africa/Juba
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 2.92s J3 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:6B963FA21CF4392A]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748) {code}
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=DBF7318E39CB980F
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.31s J1 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:CA436B6980428CF9]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#65
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672282#comment-16672282
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 10:01 PM:
---
Two failures associated with this run.
Commit: a092f1a79edbf0092f96155414215b443363c2fb
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=DBF7318E39CB980F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=he-IL -Dtests.timezone=Africa/Juba
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 2.92s J3 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:6B963FA21CF4392A]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748) {code}
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=DBF7318E39CB980F
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.31s J1 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:CA436B6980428CF9]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#65
was (Author: risdenk):
Two failures associated with this run.
Commit: a092f1a79edbf0092f96155414215b443363c2fb
Test: ExecutePlanActionTest#testIntegration
{code:java}
NOTE: reproduce with: ant test -Dtestcase=ExecutePlanActionTest
-Dtests.method=testIntegration -Dtests.seed=DBF7318E39CB980F -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=he-IL -Dtests.timezone=Africa/Juba
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 2.92s J3 | ExecutePlanActionTest.testIntegration <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<2> but
was:<1>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:6B963FA21CF4392A]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:224)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
reproduce with: ant test -Dtestcase=NodeLostTriggerTest
-Dtests.method=testListenerAcceptance -Dtests.seed=DBF7318E39CB980F
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-Latn-ME
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 0.31s J1 | NodeLostTriggerTest.testListenerAcceptance <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but
was:<0>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBF7318E39CB980F:CA436B6980428CF9]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:265)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#65
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672283#comment-16672283
]
Kevin Risden edited comment on SOLR-12932 at 11/1/18 10:02 PM:
---
Commit: af0d46ac4c7f2c3975a539b69de011c02538f361
Test: TestSystemCollAutoCreate#testAutoCreate
{code:java}
reproduce with: ant test -Dtestcase=TestSystemCollAutoCreate
-Dtests.method=testAutoCreate -Dtests.seed=FEB73B4EC4B46883 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=America/Tortola
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 32.7s J1 | TestSystemCollAutoCreate.testAutoCreate <<<
[junit4]> Throwable #1: java.lang.AssertionError: Could not successfully
add blob after 150 attempts. Expecting 2 items. time elapsed 15,499 output
for url is {
[junit4]> "responseHeader":{
[junit4]> "zkConnected":true,
[junit4]> "status":0,
[junit4]> "QTime":0},
[junit4]> "response":{
[junit4]> "numFound":1,
[junit4]> "start":0,
[junit4]> "docs":[{
[junit4]> "id":"test/1",
[junit4]> "md5":"710177b50a8305661e0d0918ebf14e0a",
[junit4]> "blobName":"test",
[junit4]> "version":1,
[junit4]> "timestamp":"2018-11-01T21:07:34.341Z",
[junit4]> "size":2048}]}}
[junit4]>at
__randomizedtesting.SeedInfo.seed([FEB73B4EC4B46883:C1EC8F9F72CAA1EE]:0)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.postAndCheck(TestBlobHandler.java:140)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.checkBlobPost(TestBlobHandler.java:102)
[junit4]>at
org.apache.solr.handler.TestSystemCollAutoCreate.testAutoCreate(TestSystemCollAutoCreate.java:26)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
Reference: risdenk/nuc#72
was (Author: risdenk):
Commit: af0d46ac4c7f2c3975a539b69de011c02538f361
Test: TestSystemCollAutoCreate#testAutoCreate
{code:java}
reproduce with: ant test -Dtestcase=TestSystemCollAutoCreate
-Dtests.method=testAutoCreate -Dtests.seed=FEB73B4EC4B46883 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=America/Tortola
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 32.7s J1 | TestSystemCollAutoCreate.testAutoCreate <<<
[junit4]> Throwable #1: java.lang.AssertionError: Could not successfully
add blob after 150 attempts. Expecting 2 items. time elapsed 15,499 output
for url is {
[junit4]> "responseHeader":{
[junit4]> "zkConnected":true,
[junit4]> "status":0,
[junit4]> "QTime":0},
[junit4]> "response":{
[junit4]> "numFound":1,
[junit4]> "start":0,
[junit4]> "docs":[{
[junit4]> "id":"test/1",
[junit4]> "md5":"710177b50a8305661e0d0918ebf14e0a",
[junit4]> "blobName":"test",
[junit4]> "version":1,
[junit4]> "timestamp":"2018-11-01T21:07:34.341Z",
[junit4]> "size":2048}]}}
[junit4]>at
__randomizedtesting.SeedInfo.seed([FEB73B4EC4B46883:C1EC8F9F72CAA1EE]:0)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.postAndCheck(TestBlobHandler.java:140)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.checkBlobPost(TestBlobHandler.java:102)
[junit4]>at
org.apache.solr.handler.TestSystemCollAutoCreate.testAutoCreate(TestSystemCollAutoCreate.java:26)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
Reference: risdenk/nuc#72
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will e
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672283#comment-16672283
]
Kevin Risden commented on SOLR-12932:
-
Commit: af0d46ac4c7f2c3975a539b69de011c02538f361
Test: TestSystemCollAutoCreate#testAutoCreate
{code:java}
reproduce with: ant test -Dtestcase=TestSystemCollAutoCreate
-Dtests.method=testAutoCreate -Dtests.seed=FEB73B4EC4B46883 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=America/Tortola
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] FAILURE 32.7s J1 | TestSystemCollAutoCreate.testAutoCreate <<<
[junit4]> Throwable #1: java.lang.AssertionError: Could not successfully
add blob after 150 attempts. Expecting 2 items. time elapsed 15,499 output
for url is {
[junit4]> "responseHeader":{
[junit4]> "zkConnected":true,
[junit4]> "status":0,
[junit4]> "QTime":0},
[junit4]> "response":{
[junit4]> "numFound":1,
[junit4]> "start":0,
[junit4]> "docs":[{
[junit4]> "id":"test/1",
[junit4]> "md5":"710177b50a8305661e0d0918ebf14e0a",
[junit4]> "blobName":"test",
[junit4]> "version":1,
[junit4]> "timestamp":"2018-11-01T21:07:34.341Z",
[junit4]> "size":2048}]}}
[junit4]>at
__randomizedtesting.SeedInfo.seed([FEB73B4EC4B46883:C1EC8F9F72CAA1EE]:0)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.postAndCheck(TestBlobHandler.java:140)
[junit4]>at
org.apache.solr.handler.TestBlobHandler.checkBlobPost(TestBlobHandler.java:102)
[junit4]>at
org.apache.solr.handler.TestSystemCollAutoCreate.testAutoCreate(TestSystemCollAutoCreate.java:26)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1065)
[junit4]>at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1039)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{code}
Reference: risdenk/nuc#72
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673409#comment-16673409
]
Kevin Risden commented on SOLR-12932:
-
Last few builds have been clean. This most recent one had a new failure.
Commit: 91b202bad89a94d40021251e026c582f695aad69
Test: MathExpressionTest#testDistributions
{code:java}
reproduce with: ant test -Dtestcase=MathExpressionTest
-Dtests.method=testDistributions -Dtests.seed=F7286DC596D3A9BA
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-VE
-Dtests.timezone=Pacific/Pago_Pago -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.09s J1 | MathExpressionTest.testDistributions <<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
__randomizedtesting.SeedInfo.seed([F7286DC596D3A9BA:48D72C6F48294926]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testDistributions(MathExpressionTest.java:1704)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673409#comment-16673409
]
Kevin Risden edited comment on SOLR-12932 at 11/2/18 4:56 PM:
--
Last few builds have been clean. This most recent one had a new failure.
Commit: 91b202bad89a94d40021251e026c582f695aad69
Test: MathExpressionTest#testDistributions
{code:java}
reproduce with: ant test -Dtestcase=MathExpressionTest
-Dtests.method=testDistributions -Dtests.seed=F7286DC596D3A9BA
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-VE
-Dtests.timezone=Pacific/Pago_Pago -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.09s J1 | MathExpressionTest.testDistributions <<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
__randomizedtesting.SeedInfo.seed([F7286DC596D3A9BA:48D72C6F48294926]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testDistributions(MathExpressionTest.java:1704)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
Reference: risdenk/nuc#108
was (Author: risdenk):
Last few builds have been clean. This most recent one had a new failure.
Commit: 91b202bad89a94d40021251e026c582f695aad69
Test: MathExpressionTest#testDistributions
{code:java}
reproduce with: ant test -Dtestcase=MathExpressionTest
-Dtests.method=testDistributions -Dtests.seed=F7286DC596D3A9BA
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-VE
-Dtests.timezone=Pacific/Pago_Pago -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 0.09s J1 | MathExpressionTest.testDistributions <<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
__randomizedtesting.SeedInfo.seed([F7286DC596D3A9BA:48D72C6F48294926]:0)
[junit4]>at
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testDistributions(MathExpressionTest.java:1704)
[junit4]>at java.lang.Thread.run(Thread.java:748){code}
> ant test (without badapples=false) should pass easily for developers.
> -
>
> Key: SOLR-12932
> URL: https://issues.apache.org/jira/browse/SOLR-12932
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>
> If we fix the tests we will end up here anyway, but we can shortcut this.
> Once I get my first patch in, anyone who mentions a test that fails locally
> for them at any time (not jenkins), I will fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[
https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675354#comment-16675354
]
Kevin Risden commented on SOLR-12932:
-
I had stopped the runs for the weekend but this morning 5/5 failed with the
same test failure.
Commit:34500a1262f2a7a6602e43904facc7da958e0cd1
Test:AutoscalingHistoryHandlerTest
{code:java}
reproduce with: ant test -Dtestcase=AutoscalingHistoryHandlerTest
-Dtests.seed=8F97179111B556A4 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=sr-BA -Dtests.timezone=Cuba -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.00s J1 | AutoscalingHistoryHandlerTest (suite) <<<
[junit4]> Throwable #1: java.lang.AssertionError: ObjectTracker found 2
object(s) that were not released!!! [ZkStateReader, SolrZkClient]
[junit4]>
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException:
org.apache.solr.common.cloud.ZkStateReader
[junit4]>at
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
[junit4]>at
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:328)
[junit4]>at
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:936)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:899)
[junit4]>at
org.apache.solr.metrics.rrd.SolrRrdBackendFactory.remove(SolrRrdBackendFactory.java:320)
[junit4]>at
org.apache.solr.handler.admin.MetricsHistoryHandler.removeHistory(MetricsHistoryHandler.java:302)
[junit4]>at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$1(CoreAdminOperation.java:121)
[junit4]>at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
[junit4]>at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:395)
[junit4]>at
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
[junit4]>at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
[junit4]>at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit4]>at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4]>
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException:
org.apache.solr.common.cloud.SolrZkClient
[junit4]>at
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
[junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:203)
[junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)
[junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)
[junit4]>at
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:306)
[junit4]>at
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
[junit4]>at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
[junit4]>at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:936)
[junit4]>at
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:899)
[junit4]>at
org.apache.solr.metrics.rrd.SolrRrdBackendFactory.remove(SolrRrdBackendFactory.java:320)
[junit4]>at
org.apache.solr.handler.admin.MetricsHistoryHandler.removeHistory(MetricsHistoryHandler.java:302)
[jira] [Commented] (SOLR-12932) ant test (without badapples=false) should pass easily for developers.
[ https://issues.apache.org/jira/browse/SOLR-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676707#comment-16676707 ] Kevin Risden commented on SOLR-12932: - Looks like there have been new commits and that last 5 tests have passed successfully. > ant test (without badapples=false) should pass easily for developers. > - > > Key: SOLR-12932 > URL: https://issues.apache.org/jira/browse/SOLR-12932 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > If we fix the tests we will end up here anyway, but we can shortcut this. > Once I get my first patch in, anyone who mentions a test that fails locally > for them at any time (not jenkins), I will fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12969) Solr replication failure
[ https://issues.apache.org/jira/browse/SOLR-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677277#comment-16677277 ] Kevin Risden commented on SOLR-12969: - [~caomanhdat] - Do you have any ideas here? I think you did work on replication. > Solr replication failure > > > Key: SOLR-12969 > URL: https://issues.apache.org/jira/browse/SOLR-12969 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Reporter: Jeremy Smith >Priority: Major > > Under certain circumstances, replication fails between a leader and follower. > The follower will not receive updates from the leader, even though the > leader has a newer version. If the leader is restarted, it will get the > older version from the follower. > > This was discussed on the [mailing > list|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201810.mbox/%3CBYAPR04MB4406710795EA07E93BF80913ADCD0%40BYAPR04MB4406.namprd04.prod.outlook.com%3E] > and [~risdenk] [wrote a > script|https://github.com/risdenk/test-solr-start-stop-replica-consistency] > that demonstrates this error. He also verified that the error occurs when > the script is run outside of docker. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875877#comment-16875877
]
Kevin Risden commented on SOLR-13587:
-
Yea so HDFS filesystem instances can't be closed. Sadly. I looked into this as
part of SOLR-5007. I found the same thing that backup repositories don't
open/close things properly. Probably hidden by the fact that HDFS leaks threads.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875878#comment-16875878
]
Kevin Risden commented on SOLR-13587:
-
And when I say "can't" I mean literally there is no close option on an HDFS
filesystem instance. It leaks threads since the filesystem instance starts some
thread pools and has no close method to stop them. It would be great if we
could actually call close on an HDFS filesystem, but nope.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876440#comment-16876440
]
Kevin Risden commented on SOLR-13587:
-
[~mkhludnev] - No I asked around and didn't seem to be any way to work around
the HDFS close stuff. Would need to be fixed in Hadoop first.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720571#comment-16720571 ] Kevin Risden commented on SOLR-12727: - [~erickerickson] - yes it is test only. ZkTestServer 127.0.0.1 -> localhost change looks to have been unnecessary from the above patch. Switching ZkTestServer getZkHost() and getZkAddress() back to 127.0.0.1 all tests pass with and without /etc/hosts changes. > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: master (8.0), 7.7 > > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch, > SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721655#comment-16721655 ] Kevin Risden commented on SOLR-12727: - [~erickerickson] - Thanks! > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: master (8.0), 7.7 > > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch, > SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
Kevin Risden created SOLR-13726: --- Summary: Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly Key: SOLR-13726 URL: https://issues.apache.org/jira/browse/SOLR-13726 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Kevin Risden Solr should avoid setting system properties that affect the entire JVM. Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause a bunch of issues if SolrJ is colocated with other Kerberos secured services. Krb5HttpClientBuilder changes the JVM default to false if it is not set. It is defaulting to true. This affects everything in the JVM. Since SolrJ is meant to be client side, we should avoid doing this. [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918804#comment-16918804 ] Kevin Risden commented on SOLR-13726: - SOLR-7468 introduced this a long time ago. This came up recently while trying to debug an issue where the JVM hangs looking for Kerberos credentials. javax.security.auth.useSubjectCredsOnly=false causes this behavior. We should therefore definitely avoid setting the property. The warning should be enough to help correct this. In an ideal world, the SolrJ kerberos handling would automatically set the Java Subject and not have to worry about this setting being configured at all. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918806#comment-16918806 ] Kevin Risden commented on SOLR-13726: - Some references about useSubjectCredsOnly: * Source where default is true - http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/jgss/GSSUtil.java#l259 * ugly issue where causes hung threads - https://risdenk.github.io/2018/03/15/hdf-apache-nifi-kerberos-errors-usesubjectcredsonly.html > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13726: Component/s: SolrJ > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918808#comment-16918808 ] Kevin Risden commented on SOLR-13726: - [~anshum] - curious if you have any opinions/thoughts here on not setting the useSubjectCredsOnly system property. I don't have a patch yet - since I think overall this needs a bit more thought about how we handle Kerberos in SolrJ. Ideally we wrap every SolrJ call internally with the explicit subject. This would avoid having to fall back to the JVM JAAS config unless explicitly required. The Hadoop UserGroupInformation class wraps a lot of the ugly internals of JVM JAAS configs, but it is a pretty heavy dependency to bring into SolrJ (its part of hadoop-common). But it might give some ideas on how to better handle this. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6327) ArrayIndexOutOfBoundsException in reading a lucene block
[
https://issues.apache.org/jira/browse/LUCENE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650924#comment-16650924
]
Kevin Risden commented on LUCENE-6327:
--
[~vamsee] - Was this index on HDFS? Any chance you were able to find the root
cause for this?
> ArrayIndexOutOfBoundsException in reading a lucene block
>
>
> Key: LUCENE-6327
> URL: https://issues.apache.org/jira/browse/LUCENE-6327
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Vamsee Yarlagadda
>Priority: Minor
>
> I notice this error while trying to do heavy indexing in Solr. This error was
> seen in testing Cloudera Search (Solr 4.4 with lots of SolrCloud, other
> critical bug fixes)
> {code}
> 2015-02-27 04:21:46,644 INFO org.apache.solr.core.SolrCore.Request:
> [crunch_sequence_collection_shard2_replica5] webapp=/solr path=/update
> params={distrib.from=http://search-15.vpc.cloudera.com:8983/solr/crunch_sequence_collection_shard2_replica2/&update.distrib=FROMLEADER&wt=javabin&version=2}
> status=0 QTime=246
> 2015-02-27 04:21:46,773 ERROR org.apache.solr.core.SolrCore:
> java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.fillTerm(BlockTreeTermsReader.java:2934)
> at
> org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.scanToTermLeaf(BlockTreeTermsReader.java:2743)
> at
> org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.scanToTerm(BlockTreeTermsReader.java:2662)
> at
> org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.seekExact(BlockTreeTermsReader.java:1695)
> at
> org.apache.solr.search.SolrIndexSearcher.lookupId(SolrIndexSearcher.java:746)
> at
> org.apache.solr.update.VersionInfo.getVersionFromIndex(VersionInfo.java:193)
> at org.apache.solr.update.UpdateLog.lookupVersion(UpdateLog.java:739)
> at
> org.apache.solr.update.VersionInfo.lookupVersion(VersionInfo.java:183)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:716)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:459)
> at
> org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1953)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:766)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.solr.servlet.SolrHadoopAuthenticationFilter$2.doFilter(SolrHadoopAuthenticationFilter.java:272)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:592)
> at
> org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationFilter.doFilter(DelegationTokenAuthenticationFilter.java:277)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:555)
> at
> org.apache.solr.servlet.SolrHadoopAuthenticationFilter.doFilter(SolrHadoopAuthenticationFilter.java:277)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.solr.servlet.HostnameFilter.doFilter(HostnameFilter.java:86)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalin
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[
https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16698930#comment-16698930
]
Kevin Risden commented on SOLR-12727:
-
[~erickerickson] - I can take a look this week on this. I think if you run the
following it should point you where to add the two additional lines:
{code:java}
git grep -F "permission javax.security.auth.kerberos.ServicePermission"
{code}
Changing the minimal number of things to makes tests pass sounds good to me.
Only in some of the kerberos code should the localhost vs 127.0.0.1 distinction
matter.
> Upgrade ZooKeeper dependency to 3.4.13
> --
>
> Key: SOLR-12727
> URL: https://issues.apache.org/jira/browse/SOLR-12727
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12727.patch, SOLR-12727.patch
>
>
> Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make
> the ZK client re-resolve the server hostnames when a connection fails. This
> will fix issues where a failed ZK container is replaced with a new one that
> has a different IP address and DNS gets updated with the new address.
> Typically these upgrades do not require code changes, but that should be
> verified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12644) Supporting AuthenticationPlugin for Http2SolrClient
[ https://issues.apache.org/jira/browse/SOLR-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610901#comment-16610901 ] Kevin Risden commented on SOLR-12644: - I was doing some research on HTTP/2 and found that Kerberos/NTLM is not supported with HTTP/2? It looks like most servers will fall back to HTTP 1.1 if Kerberos authentication is required. I don't know if there is any way to work around this. Searching for "http/2 kerberos" in Google isn't promising. > Supporting AuthenticationPlugin for Http2SolrClient > --- > > Key: SOLR-12644 > URL: https://issues.apache.org/jira/browse/SOLR-12644 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12644.patch > > > All the tests of AuthenticationPlugin classes are marked as ignored. This > ticket aims to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12639) Umbrella JIRA for adding support HTTP/2, jira/http2
[ https://issues.apache.org/jira/browse/SOLR-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610902#comment-16610902 ] Kevin Risden commented on SOLR-12639: - I was doing some research on HTTP/2 and found that Kerberos/NTLM is not supported with HTTP/2? It looks like most servers will fall back to HTTP 1.1 if Kerberos authentication is required. I don't know if there is any way to work around this. Searching for "http/2 kerberos" in Google isn't promising. > Umbrella JIRA for adding support HTTP/2, jira/http2 > --- > > Key: SOLR-12639 > URL: https://issues.apache.org/jira/browse/SOLR-12639 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: http2 >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > > This ticket will aim to replace/add support of http2 by using jetty HTTP > client to Solr. All the works will be committed to jira/http2 branch. This > branch will be served like a stepping stone between the master branch and > Mark Miller starburst branch. I will try to keep jira/http2 as close as > master as possible (this will make merging in the future easier). In the same > time, changes in starburst branch will be split into smaller/testable parts > then push it to jira/http2 branch. > Anyone who interests at http2 for Solr can use jira/http2 branch but there is > no backward-compatibility guarantee. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16710563#comment-16710563 ] Kevin Risden commented on SOLR-12727: - Sorry I haven't had a chance to look. $DayJob :) I'll try to look when I get a few minutes. > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713013#comment-16713013 ] Kevin Risden commented on SOLR-12727: - Taking a look and they don't seem to fail in my IDE but the failures reproduce from the command line. It looks like there might be some unrelated changes added to the patch that cause this. I am looking into it a bit further. > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[
https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713078#comment-16713078
]
Kevin Risden commented on SOLR-12727:
-
[~erickerickson] - I just uploaded a patch that passed all Solr tests.
{code:java}
ant clean clean-jars jar-checksums compile
cd solr
ant test
{code}
> Upgrade ZooKeeper dependency to 3.4.13
> --
>
> Key: SOLR-12727
> URL: https://issues.apache.org/jira/browse/SOLR-12727
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch,
> SOLR-12727.patch
>
>
> Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make
> the ZK client re-resolve the server hostnames when a connection fails. This
> will fix issues where a failed ZK container is replaced with a new one that
> has a different IP address and DNS gets updated with the new address.
> Typically these upgrades do not require code changes, but that should be
> verified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-12727: Attachment: SOLR-12727.patch > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch, > SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12727) Upgrade ZooKeeper dependency to 3.4.13
[ https://issues.apache.org/jira/browse/SOLR-12727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713079#comment-16713079 ] Kevin Risden commented on SOLR-12727: - It reverts some of the HTTP/localhost changes since those aren't necessary for this. > Upgrade ZooKeeper dependency to 3.4.13 > -- > > Key: SOLR-12727 > URL: https://issues.apache.org/jira/browse/SOLR-12727 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 7.4 >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-12727.patch, SOLR-12727.patch, SOLR-12727.patch, > SOLR-12727.patch > > > Upgrade ZK dependency to 3.4.13. This fixes ZOOKEEPER-2184 which will make > the ZK client re-resolve the server hostnames when a connection fails. This > will fix issues where a failed ZK container is replaced with a new one that > has a different IP address and DNS gets updated with the new address. > Typically these upgrades do not require code changes, but that should be > verified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755060#comment-16755060 ] Kevin Risden commented on SOLR-9515: Updated patch to master with HDFS tests passing. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9515: --- Attachment: SOLR-9515.patch > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756351#comment-16756351 ] Kevin Risden commented on SOLR-9515: Added missing dependencies like re2j for Hadoop on Kerberos. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756401#comment-16756401
]
Kevin Risden commented on SOLR-9515:
The precommit failures from above for Hadoop are real but they are an issue
with commons-lang3. I just sent a message to the commons-lang3 mailing list. I
have seen these errors sporadically as well. The stacktrace that is similar is:
{code:java}
ava.lang.ArrayIndexOutOfBoundsException: 4
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter$TextField.appendTo(FastDatePrinter.java:901)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRules(FastDatePrinter.java:573)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRulesToString(FastDatePrinter.java:455)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.format(FastDatePrinter.java:446)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDateFormat.format(FastDateFormat.java:428)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DirectoryScanner.start(DirectoryScanner.java:281)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initDirectoryScanner(DataNode.java:1090)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1686)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:390)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:280)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:819)
[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
{code}
This happens when the locale is set. I haven't nailed down which locales all
fail but a simple reproducing test case without Hadoop or Lucene/Solr is here:
{code:java}
long timestamp = System.currentTimeMillis();
Locale.setDefault(Locale.forLanguageTag("ja-JP-u-ca-japanese-x-lvariant-JP"));
Assert.assertEquals(SimpleDateFormat.getInstance().format(timestamp),
FastDateFormat.getInstance().format(timestamp));
{code}
This is with commons-lang3 3.8.1 the latest release.
> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared.
> I'll start up a dev branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756430#comment-16756430 ] Kevin Risden commented on SOLR-9515: [~gerlowskija] there are some more details on the PR in comments about HttpServer2. Near the bottom here: [https://github.com/apache/lucene-solr/pull/553] Gist: Lucene in integration tests spins up a Hadoop cluster which HttpServer2 (from Hadoop internally). It only works on Jetty 9.3 but we have Jetty 9.4. So copied/patched HttpServer2 to make the integration tests work. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756430#comment-16756430 ] Kevin Risden edited comment on SOLR-9515 at 1/30/19 7:03 PM: - [~gerlowskija] there are some more details on the PR in comments about HttpServer2. Near the bottom here: [https://github.com/apache/lucene-solr/pull/553] Gist: Lucene in integration tests spins up a Hadoop cluster which uses HttpServer2 (from Hadoop internally). It only works on Jetty 9.3 but we have Jetty 9.4. So copied/patched HttpServer2 to make the integration tests work. was (Author: risdenk): [~gerlowskija] there are some more details on the PR in comments about HttpServer2. Near the bottom here: [https://github.com/apache/lucene-solr/pull/553] Gist: Lucene in integration tests spins up a Hadoop cluster which HttpServer2 (from Hadoop internally). It only works on Jetty 9.3 but we have Jetty 9.4. So copied/patched HttpServer2 to make the integration tests work. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756513#comment-16756513 ] Kevin Risden commented on SOLR-9515: Added assumption check to HdfsTestUtil to avoid not run the test if FastDateFormat fails with current locale. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9515: --- Attachment: SOLR-9515.patch > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756401#comment-16756401
]
Kevin Risden edited comment on SOLR-9515 at 1/30/19 9:13 PM:
-
The precommit failures from above for Hadoop are real but they are an issue
with commons-lang3. I just sent a [message to the commons-lang3 mailing
list|http://mail-archives.apache.org/mod_mbox/commons-user/201901.mbox/%3CCAJU9nmhqgzh7VcxyhJNfb4czC2SvJzZd4o6ARcuD4msof1U2Zw%40mail.gmail.com%3E].
I have seen these errors sporadically as well. The stacktrace that is similar
is:
{code:java}
ava.lang.ArrayIndexOutOfBoundsException: 4
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter$TextField.appendTo(FastDatePrinter.java:901)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRules(FastDatePrinter.java:573)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRulesToString(FastDatePrinter.java:455)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.format(FastDatePrinter.java:446)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDateFormat.format(FastDateFormat.java:428)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DirectoryScanner.start(DirectoryScanner.java:281)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initDirectoryScanner(DataNode.java:1090)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1686)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:390)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:280)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:819)
[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
{code}
This happens when the locale is set. I haven't nailed down which locales all
fail but a simple reproducing test case without Hadoop or Lucene/Solr is here:
{code:java}
long timestamp = System.currentTimeMillis();
Locale.setDefault(Locale.forLanguageTag("ja-JP-u-ca-japanese-x-lvariant-JP"));
Assert.assertEquals(SimpleDateFormat.getInstance().format(timestamp),
FastDateFormat.getInstance().format(timestamp));
{code}
This is with commons-lang3 3.8.1 the latest release.
was (Author: risdenk):
The precommit failures from above for Hadoop are real but they are an issue
with commons-lang3. I just sent a message to the commons-lang3 mailing list. I
have seen these errors sporadically as well. The stacktrace that is similar is:
{code:java}
ava.lang.ArrayIndexOutOfBoundsException: 4
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter$TextField.appendTo(FastDatePrinter.java:901)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRules(FastDatePrinter.java:573)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.applyRulesToString(FastDatePrinter.java:455)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDatePrinter.format(FastDatePrinter.java:446)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.commons.lang3.time.FastDateFormat.format(FastDateFormat.java:428)
~[commons-lang3-3.7.jar:3.7]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DirectoryScanner.start(DirectoryScanner.java:281)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initDirectoryScanner(DataNode.java:1090)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1686)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:390)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:280)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:819)
[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
{code}
This happens when the locale is set. I haven't nailed down which locales all
fail but a simple reproducing
[jira] [Updated] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9515: --- Attachment: SOLR-9515.patch > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756584#comment-16756584 ] Kevin Risden commented on SOLR-9515: Latest patch fixes the forbiddenapis warning. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9515: --- Attachment: SOLR-9515.patch > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9515: --- Priority: Blocker (was: Major) > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Blocker > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757559#comment-16757559 ] Kevin Risden commented on SOLR-9515: Last patch is squashed commits from PR plus CHANGES.txt. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Blocker > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13092) Solr's Maven pom declares both org.codehaus.jackson and com.fasterxml.jackson
[ https://issues.apache.org/jira/browse/SOLR-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-13092. - Resolution: Duplicate Superceded by SOLR-9515 > Solr's Maven pom declares both org.codehaus.jackson and com.fasterxml.jackson > - > > Key: SOLR-13092 > URL: https://issues.apache.org/jira/browse/SOLR-13092 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Petar Tahchiev >Priority: Major > > The pom.xml in the maven repository of dataimporthandler: > view-source:https://repo1.maven.org/maven2/org/apache/solr/solr-dataimporthandler/7.6.0/solr-dataimporthandler-7.6.0.pom > declares both com.fasterxml.jackson and org.codehaus.jackson. This is a bug > and it is stopping me form upgrading my app to fasterxml jackson. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13092) Solr's Maven pom declares both org.codehaus.jackson and com.fasterxml.jackson
[ https://issues.apache.org/jira/browse/SOLR-13092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757581#comment-16757581 ] Kevin Risden commented on SOLR-13092: - I'm pretty sure this is resolved by the Hadoop 3 upgrade as the link suggests. Hadoop 3.2 only depends on old jackson stuff for YARN which we don't pull in. So that removes the dependency from the Solr side. I'm hopeful this sticks in the 8.0 release coming up. Marking as resolved since it is superceded by the Hadoop 3 upgrade ticket. > Solr's Maven pom declares both org.codehaus.jackson and com.fasterxml.jackson > - > > Key: SOLR-13092 > URL: https://issues.apache.org/jira/browse/SOLR-13092 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Petar Tahchiev >Priority: Major > > The pom.xml in the maven repository of dataimporthandler: > view-source:https://repo1.maven.org/maven2/org/apache/solr/solr-dataimporthandler/7.6.0/solr-dataimporthandler-7.6.0.pom > declares both com.fasterxml.jackson and org.codehaus.jackson. This is a bug > and it is stopping me form upgrading my app to fasterxml jackson. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757746#comment-16757746
]
Kevin Risden edited comment on SOLR-9515 at 1/31/19 9:48 PM:
-
So this caused failures on JDK9+ not sure how the below is possible
currently since solr-tests.policy
([https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L27)]
allows read access to that path.
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23605]
{code:java}
[junit4] 2> java.io.IOException: Failed to start sub tasks to add replica in
replica map :java.security.AccessControlException: access denied
("java.io.FilePermission"
"/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.index.hdfs.CheckHdfsIndexTest_B3EBC148FC827CD8-001/tempDir-001/hdfsBaseDir/data/data3/current/BP-669531916-88.99.242.108-1548970895105/current/finalized"
"read")
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice.getVolumeMap(BlockPoolSlice.java:439)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeImpl.getVolumeMap(FsVolumeImpl.java:1003)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeList$1.run(FsVolumeList.java:201)
~[hadoop-hdfs-3.2.0.jar:?]
{code}
Snippet from solr-tests.policy:
{code:java}
permission java.io.FilePermission "<>", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}jacoco.db", "write";
permission java.io.FilePermission "${junit4.tempDir}${/}*",
"read,execute,write,delete";
permission java.io.FilePermission "${clover.db.dir}${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${tests.linedocsfile}", "read";
permission java.nio.file.LinkPermission "hard";
{code}
Variables from run:
{code:java}
junit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0
junit.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp{code}
So we should have read on the paths that HDFS is trying to use?
was (Author: risdenk):
So this caused failures on JDK9+ not sure how the below is possible
currently since solr-tests.policy allows read access to that path.
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23605
{code:java}
[junit4] 2> java.io.IOException: Failed to start sub tasks to add replica in
replica map :java.security.AccessControlException: access denied
("java.io.FilePermission"
"/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.index.hdfs.CheckHdfsIndexTest_B3EBC148FC827CD8-001/tempDir-001/hdfsBaseDir/data/data3/current/BP-669531916-88.99.242.108-1548970895105/current/finalized"
"read")
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice.getVolumeMap(BlockPoolSlice.java:439)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeImpl.getVolumeMap(FsVolumeImpl.java:1003)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeList$1.run(FsVolumeList.java:201)
~[hadoop-hdfs-3.2.0.jar:?]
{code}
> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Assignee: Kevin Risden
>Priority: Blocker
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch,
> SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared.
> I'll start up a dev branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757746#comment-16757746
]
Kevin Risden commented on SOLR-9515:
So this caused failures on JDK9+ not sure how the below is possible
currently since solr-tests.policy allows read access to that path.
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23605
{code:java}
[junit4] 2> java.io.IOException: Failed to start sub tasks to add replica in
replica map :java.security.AccessControlException: access denied
("java.io.FilePermission"
"/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.index.hdfs.CheckHdfsIndexTest_B3EBC148FC827CD8-001/tempDir-001/hdfsBaseDir/data/data3/current/BP-669531916-88.99.242.108-1548970895105/current/finalized"
"read")
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice.getVolumeMap(BlockPoolSlice.java:439)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeImpl.getVolumeMap(FsVolumeImpl.java:1003)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeList$1.run(FsVolumeList.java:201)
~[hadoop-hdfs-3.2.0.jar:?]
{code}
> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Assignee: Kevin Risden
>Priority: Blocker
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch,
> SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared.
> I'll start up a dev branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757746#comment-16757746
]
Kevin Risden edited comment on SOLR-9515 at 1/31/19 10:08 PM:
--
So this caused failures on JDK9+ not sure how the below is possible
currently since solr-tests.policy
([https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L27)]
allows read access to that path.
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23605]
{code:java}
[junit4] 2> java.io.IOException: Failed to start sub tasks to add replica in
replica map :java.security.AccessControlException: access denied
("java.io.FilePermission"
"/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.index.hdfs.CheckHdfsIndexTest_B3EBC148FC827CD8-001/tempDir-001/hdfsBaseDir/data/data3/current/BP-669531916-88.99.242.108-1548970895105/current/finalized"
"read")
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice.getVolumeMap(BlockPoolSlice.java:439)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeImpl.getVolumeMap(FsVolumeImpl.java:1003)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeList$1.run(FsVolumeList.java:201)
~[hadoop-hdfs-3.2.0.jar:?]
{code}
Snippet from solr-tests.policy:
{code:java}
permission java.io.FilePermission "<>", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}jacoco.db", "write";
permission java.io.FilePermission "${junit4.tempDir}${/}*",
"read,execute,write,delete";
permission java.io.FilePermission "${clover.db.dir}${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${tests.linedocsfile}", "read";
permission java.nio.file.LinkPermission "hard";
{code}
Variables from run:
{code:java}
junit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0
junit.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp
java.security.manager=org.apache.lucene.util.TestSecurityManager
java.security.policy/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/solr-tests.policy{code}
So we should have read on the paths that HDFS is trying to use?
was (Author: risdenk):
So this caused failures on JDK9+ not sure how the below is possible
currently since solr-tests.policy
([https://github.com/apache/lucene-solr/blob/master/lucene/tools/junit4/solr-tests.policy#L27)]
allows read access to that path.
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23605]
{code:java}
[junit4] 2> java.io.IOException: Failed to start sub tasks to add replica in
replica map :java.security.AccessControlException: access denied
("java.io.FilePermission"
"/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.index.hdfs.CheckHdfsIndexTest_B3EBC148FC827CD8-001/tempDir-001/hdfsBaseDir/data/data3/current/BP-669531916-88.99.242.108-1548970895105/current/finalized"
"read")
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice.getVolumeMap(BlockPoolSlice.java:439)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeImpl.getVolumeMap(FsVolumeImpl.java:1003)
~[hadoop-hdfs-3.2.0.jar:?]
[junit4] 2>at
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsVolumeList$1.run(FsVolumeList.java:201)
~[hadoop-hdfs-3.2.0.jar:?]
{code}
Snippet from solr-tests.policy:
{code:java}
permission java.io.FilePermission "<>", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}", "read,execute";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}temp${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${junit4.childvm.cwd}${/}jacoco.db", "write";
permission java.io.FilePermission "${junit4.tempDir}${/}*",
"read,execute,write,delete";
permission java.io.FilePermission "${clover.db.dir}${/}-",
"read,execute,write,delete";
permission java.io.FilePermission "${tests.linedocsfile}", "read";
permission java.nio.file.LinkPermission "hard";
{code}
Variables from run:
{code:java}
junit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0
junit.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp{code}
So we should have rea
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757773#comment-16757773 ] Kevin Risden commented on SOLR-9515: I had tested with just JDK8. This does reproduce locally though with JDK11. I checked the failure locally and don't see any symlinks in the path going down. I can revert the master commit since I don't have this working on JDK9+ yet. Sigh. I was going to try a few configs from here: https://docs.oracle.com/javase/10/security/permissions-jdk1.htm#JSSEC-GUID-83063225-0ACB-4909-9BAB-7F7D4E3749E2 > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Blocker > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757773#comment-16757773 ] Kevin Risden edited comment on SOLR-9515 at 1/31/19 10:40 PM: -- I had tested with just JDK8. This does reproduce locally with JDK11. I checked the failure locally and don't see any symlinks in the path going down. I can revert the master commit since I don't have this working on JDK9+ yet. Sigh. I was going to try a few configs from here: [https://docs.oracle.com/javase/10/security/permissions-jdk1.htm#JSSEC-GUID-83063225-0ACB-4909-9BAB-7F7D4E3749E2] was (Author: risdenk): I had tested with just JDK8. This does reproduce locally though with JDK11. I checked the failure locally and don't see any symlinks in the path going down. I can revert the master commit since I don't have this working on JDK9+ yet. Sigh. I was going to try a few configs from here: https://docs.oracle.com/javase/10/security/permissions-jdk1.htm#JSSEC-GUID-83063225-0ACB-4909-9BAB-7F7D4E3749E2 > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Blocker > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757776#comment-16757776
]
Kevin Risden commented on SOLR-9515:
Both of the following still exhibit issues:
{code:java}
ant test -Dtestcase=HdfsRecoverLeaseTest -Dtests.seed=B3EBC148FC827CD8
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-IE
-Dtests.timezone=Asia/Ulan_Bator -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
-Dargs='-Djdk.io.permissionsUseCanonicalPath=true
-Djdk.security.filePermCompat=true'
{code}
{code:java}
ant test -Dtestcase=HdfsRecoverLeaseTest -Dtests.seed=B3EBC148FC827CD8
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-IE
-Dtests.timezone=Asia/Ulan_Bator -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1 -Djdk.io.permissionsUseCanonicalPath=true
-Djdk.security.filePermCompat=true
{code}
> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Assignee: Kevin Risden
>Priority: Blocker
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch,
> SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared.
> I'll start up a dev branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757779#comment-16757779 ] Kevin Risden commented on SOLR-9515: Yea I have been trying to debug it. I'll keep playing with it. Thanks. Glad it isn't something extremely obvious that I'm missing. > Update to Hadoop 3 > -- > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Kevin Risden >Priority: Blocker > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9515) Update to Hadoop 3
[
https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757791#comment-16757791
]
Kevin Risden commented on SOLR-9515:
Well looks like I found something that is promising. I don't know why this
would work on JDK8 though.
[https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html]
{code:java}
If a SecurityManager is present and no factory is specified, then the default
pool uses a factory supplying threads that have no Permissions enabled. The
system class loader is used to load these classes. Upon any error in
establishing these settings, default parameters are used. It is possible to
disable or limit the use of threads in the common pool by setting the
parallelism property to zero, and/or using a factory that may return null.
However doing so may cause unjoined tasks to never be executed.
{code}
[https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ForkJoinPool.html]
{code:java}
If no thread factory is supplied via a system property, then the common pool
uses a factory that uses the system class loader as the thread context class
loader. In addition, if a SecurityManager is present, then the common pool uses
a factory supplying threads that have no Permissions enabled. Upon any error in
establishing these settings, default parameters are used. It is possible to
disable or limit the use of threads in the common pool by setting the
parallelism property to zero, and/or using a factory that may return null.
However doing so may cause unjoined tasks to never be executed.{code}
From
https://github.com/apache/hadoop/blob/branch-3.2/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/BlockPoolSlice.java#L213
> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Assignee: Kevin Risden
>Priority: Blocker
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch,
> SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared.
> I'll start up a dev branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
