[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-13-rc) - Build # 24549 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24549/ Java: 64bit/jdk-13-rc -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.TestLockTree.testLocks Error Message: expected:<2> but was:<3> Stack Trace: java.lang.AssertionError: expected:<2> but was:<3> at __randomizedtesting.SeedInfo.seed([698CDCF5866383ED:1046A60C8EB36806]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.cloud.TestLockTree.testLocks(TestLockTree.java:99) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:830) Build Log: [...truncated 2039 lines...] [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190815_123125_9439732664721030066917.syserr [junit4] >>> JVM
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-14-ea+9) - Build # 24547 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24547/ Java: 64bit/jdk-14-ea+9 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI Error Message: should be a routed alias Stack Trace: java.lang.AssertionError: should be a routed alias at __randomizedtesting.SeedInfo.seed([9C51C70310DBA372:83865B2F63D05A39]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:315) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:830) Build Log: [...truncated 13083 lines...] [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest [junit4] 2> 338212 INFO (SUITE-AliasIntegrationTest-seed#[9C51C70310DBA372]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null &
[jira] [Created] (SOLR-13698) Calling Suggester via Alias fails
Eileen Mosch created SOLR-13698:
---
Summary: Calling Suggester via Alias fails
Key: SOLR-13698
URL: https://issues.apache.org/jira/browse/SOLR-13698
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Suggester
Affects Versions: 8.1.1, 8.2
Reporter: Eileen Mosch
Attachments: http_suggester_stacktrace.json
There's a problem using a multi-collection alias in combination with suggester
request. We used version 7.3.1 and had no problems, after upgrading to version
8.x exceptions are thrown.
*Details*
I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error
message: „No live SolrServers available to handle this
request:[http://[myIP]:8983/solr/WORLD“.
If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
waiting response from server at:
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
If I use single-collection Aliases (e.g. "DE") everything is fine.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12315) the number of docs in each group depends on rows
[
https://issues.apache.org/jira/browse/SOLR-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908044#comment-16908044
]
Chongchen Chen commented on SOLR-12315:
---
I tried to reproduce your problem, but failed. here's my unit test code.
can you give me your files in solr.home .
{code:java}
package org.apache.solr.cloud;
import java.util.Arrays;
import java.util.List;
import java.util.Random;
import java.util.stream.Stream;
import org.apache.solr.client.solrj.SolrQuery;
import org.apache.solr.client.solrj.impl.CloudSolrClient;
import org.apache.solr.client.solrj.request.CollectionAdminRequest;
import org.apache.solr.client.solrj.request.UpdateRequest;
import org.apache.solr.client.solrj.response.Group;
import org.apache.solr.client.solrj.response.QueryResponse;
import org.apache.solr.common.SolrInputDocument;
import org.junit.BeforeClass;
import org.junit.Test;
public class NumStableTest extends SolrCloudTestCase {
private static final String COLLECTION = "num_stable" ;
private static final int numShards = 3;
private static final int numReplicas = 2;
private static final int maxShardsPerNode = 2;
private static final int nodeCount = (numShards*numReplicas +
(maxShardsPerNode-1))/maxShardsPerNode;
private static final String id = "id";
private static final int docNum = 200;
@BeforeClass
public static void setupCluster() throws Exception {
// create and configure cluster
configureCluster(nodeCount)
.addConfig("conf", configset("cloud-dynamic"))
.configure();
// create an empty collection
CollectionAdminRequest.createCollection(COLLECTION, "conf", numShards,
numReplicas)
.setMaxShardsPerNode(maxShardsPerNode)
.process(cluster.getSolrClient());
Random rnd = random();
UpdateRequest r = new UpdateRequest();
// add documents
for(int i = 0; i < docNum; i++){
SolrInputDocument doc = sdoc(id, "1",
"monthly_payment_i", "" + rnd.nextInt(1000),
"score_d", "" + rnd.nextInt(1000),
"car_age_id_i", "" + rnd.nextInt(1000),
"car_variant_and_offer_type_s1", "" + rnd.nextInt(4));
r.add(doc);
}
r.commit(cluster.getSolrClient(), COLLECTION);
}
@Test
public void testNumStable() throws Exception {
String[] params = {
"q", "*:*",
"fl", "id",
"group.sort", "monthly_payment_i asc, score_d desc",
"group.limit", "100",
"sort", "car_age_id_i asc, score_d desc",
"debugQuery", "on",
"group.field", "car_variant_and_offer_type_s1",
"group", "true"
};
final SolrQuery solrQuery1 = new SolrQuery("rows","2", params);
final SolrQuery solrQuery2 = new SolrQuery("rows", "6", params);
final CloudSolrClient cloudSolrClient = cluster.getSolrClient();
final QueryResponse rsp1 = cloudSolrClient.query(COLLECTION, solrQuery1);
final QueryResponse rsp2 = cloudSolrClient.query(COLLECTION, solrQuery2);
final List grp1 =
rsp1.getGroupResponse().getValues().get(0).getValues();
final List grp2 =
rsp2.getGroupResponse().getValues().get(0).getValues();
assertEquals(grp1.size(), grp2.size());
int groupNum = grp1.size();
for(int i = 0; i < groupNum; i++){
Group g1 = grp1.get(i);
Group g2 = grp2.get(i);
assertEquals(g1.getResult().getNumFound(), g2.getResult().getNumFound());
}
}
}
{code}
> the number of docs in each group depends on rows
>
>
> Key: SOLR-12315
> URL: https://issues.apache.org/jira/browse/SOLR-12315
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 7.1
>Reporter: Duo Chen
>Priority: Critical
> Attachments: difference.jpeg
>
>
> Hi,
> We used Solr Cloud 7.1.0(3 nodes, 3 shards with 2 replicas). When we used
> group query, we found that the number of docs in each group depends on the
> rows number(group number).
> When the rows bigger then 5, the return docs are correct and stable, for the
> rest, the number of docs is smaller than the actual result.
> Could you please explain why and give me some suggestion about how to decide
> the rows number?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on issue #758: LUCENE-8833: Add a #load() method to IndexInput to allow preloading file content into physical memory
uschindler commented on issue #758: LUCENE-8833: Add a #load() method to
IndexInput to allow preloading file content into physical memory
URL: https://github.com/apache/lucene-solr/pull/758#issuecomment-521674174
> I am still in review (have to feed my brain with all details, reading C++
source code of JVM and so on).
>
> Because of Adrien's comment you changed the slice building to also take
the start position into account, so the slice method returns a byte buffer that
is really only a view and a call to load() would not read data of the whole CFS
file.
>
> As you changed this method to take care of the start offset/position,
please fix the javadocs comment:
>
> ```
> /** Returns a sliced view from a set of already-existing buffers:
>* the last buffer's limit() will be correct, but
>* you must deal with offset separately (the first buffer will not be
adjusted) */
> private ByteBuffer[] buildSlice(ByteBuffer[] buffers, long offset, long
length) {
> ```
I am not fully sure how the comment would look like. Currently it only fixes
the start offset for single-buffer indexinputs.
The code is horrible here, I still don't fully understand the code
difference for single and multi buffer indexinputs. IMHO, we should change the
code and make buildSlice always fix position() and limit() and build a buffer
slice for the first and last buffer. How it's done currently is hard to
understand. I cannot make any guarantees that the code behaves correctly after
this patch and I am not sure if testing of all cases is fine. Maybe only apply
to master first and let Jenkins test it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13698) Calling Suggester via Alias fails
[
https://issues.apache.org/jira/browse/SOLR-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eileen Mosch updated SOLR-13698:
Description:
There's a problem using a multi-collection alias in combination with suggester
request. We used version 7.3.1 and had no problems, after upgrading to version
8.x exceptions are thrown.
*Details*
I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error
message: „No live SolrServers available to handle this
request:[http://[myIP]:8983/solr/WORLD“.
If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
waiting response from server at:
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
If I use single-collection Aliases (e.g. "DE") everything is fine.
was:
There's a problem using a multi-collection alias in combination with suggester
request. We used version 7.3.1 and had no problems, after upgrading to version
8.x exceptions are thrown.
*Details*
I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error
message: „No live SolrServers available to handle this
request:[http://[myIP]:8983/solr/WORLD“.
If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
waiting response from server at:
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
If I use single-collection Aliases (e.g. "DE") everything is fine.
> Calling Suggester via Alias fails
> -
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with
> suggester request. We used version 7.3.1 and had no problems, after upgrading
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the
> error message: „No live SolrServers available to handle this
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
> waiting response from server at:
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
> stacktrace attached)
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
> If I use single-collection Aliases (e.g. "DE") everything is fine.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 414 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/414/ 1 tests failed. FAILED: org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime Error Message: took over 10 seconds after collection creation to update aliases Stack Trace: java.lang.AssertionError: took over 10 seconds after collection creation to update aliases at __randomizedtesting.SeedInfo.seed([A49B1CEEC4DB6F1A:A39053EDFB283EF2]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:77) at org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:480) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13462 lines...] [junit4] Suite: org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 401 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/401/ Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth Error Message: Software caused connection abort: recv failed Stack Trace: javax.net.ssl.SSLException: Software caused connection abort: recv failed at __randomizedtesting.SeedInfo.seed([6EE3FA5FE64B562D:D28D8C4D4218D557]:0) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) at org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:202) at org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:178) at org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at
[jira] [Updated] (SOLR-13698) Calling Suggester via Alias fails
[
https://issues.apache.org/jira/browse/SOLR-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eileen Mosch updated SOLR-13698:
Description:
There's a problem using a multi-collection alias in combination with suggester
request. We used version 7.3.1 and had no problems, after upgrading to version
8.x exceptions are thrown.
*Details*
I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error
message: „No live SolrServers available to handle this
request:[http://[myIP]:8983/solr/WORLD“.
If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
waiting response from server at:
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
stacktrace attached). The collection name within the error messages differs
(AT.test... or BE.test... ) but the error information is still the same.
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
If I use single-collection Aliases (e.g. "AT") everything works fine.
was:
There's a problem using a multi-collection alias in combination with suggester
request. We used version 7.3.1 and had no problems, after upgrading to version
8.x exceptions are thrown.
*Details*
I created an alias called „WORLD“ pointing to six collections.
{code:java}
// aliases.json
{"collection":{
"AT":"AT.test",
"BE":"BE.test",
"DE":"DE.test",
"FR":"FR.test",
"LU":"LU.test",
"NL":"NL.test",
"WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
}
{code}
If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the error
message: „No live SolrServers available to handle this
request:[http://[myIP]:8983/solr/WORLD“.
If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
waiting response from server at:
[http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
stacktrace attached)
{code:java}
// HTTP API Suggester Call
http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
{code}
If I use single-collection Aliases (e.g. "DE") everything is fine.
> Calling Suggester via Alias fails
> -
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with
> suggester request. We used version 7.3.1 and had no problems, after upgrading
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the
> error message: „No live SolrServers available to handle this
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
> waiting response from server at:
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
> stacktrace attached). The collection name within the error messages differs
> (AT.test... or BE.test... ) but the error information is still the same.
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
> If I use single-collection Aliases (e.g. "AT") everything works fine.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12069) Default operator parameter q.op ignored.
[
https://issues.apache.org/jira/browse/SOLR-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907945#comment-16907945
]
Chongchen Chen commented on SOLR-12069:
---
Hi, I have resolved this bug. [pull
request|https://github.com/apache/lucene-solr/pull/833]
> Default operator parameter q.op ignored.
>
>
> Key: SOLR-12069
> URL: https://issues.apache.org/jira/browse/SOLR-12069
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 7.2
>Reporter: Christoph Strobl
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{q.op}} parameter as described in the [7.2 reference for the Standard
> Query
> Parser|http://lucene.apache.org/solr/guide/7_2/the-standard-query-parser.html#standard-query-parser-parameters]
> does not get used when executing a query.
> Reproduce via _techproducts_ example.
> # {{./bin/solr -e tchproducts}}
> # {{./bin/post -c techproducts example/exampledocs/*.xml}}
> # {{http "http://localhost:8983/solr/techproducts/select?q=inStock:(true
> false)=AND"}}
> The search above is expected to return {{0}} results but instead matches all
> {{21}} entries.
> The response header lists the {{q.op}} parameter
> {code:javascript}
> {
> "responseHeader": {
> "QTime": 3,
> "params": {
> "debugQuery": "on",
> "q": "inStock:(true false)",
> "q.op": "AND"
> },
> "status": 0
> },
> // ...
> }
> {code}
> The debug output is as follows:
> {code:javascript}
> debug": {
> "QParser": "LuceneQParser",
> "explain": {
> "100-435805": "\n1.5869651 = sum of:\n 1.5869651 = weight(inStock:F in
> 31) [SchemaSimilarity], result of:\n1.5869651 = score(doc=31,freq=1.0 =
> termFreq=1.0\n), product of:\n 1.5869651 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n4.0 = docFreq\n
> 21.0 = docCount\n 1.0 = tfNorm, computed as (freq * (k1 + 1)) /
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n
> 0.0 = parameter b (norms omitted for field)\n",
> "6H500F0": "\n0.22884157 = sum of:\n 0.22884157 = weight(inStock:T in
> 2) [SchemaSimilarity], result of:\n0.22884157 = score(doc=2,freq=1.0 =
> termFreq=1.0\n), product of:\n 0.22884157 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n17.0 = docFreq\n
>21.0 = docCount\n 1.0 = tfNorm, computed as (freq * (k1 + 1)) /
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n
> 0.0 = parameter b (norms omitted for field)\n",
> "EN7800GTX/2DHTV/256M": "\n1.5869651 = sum of:\n 1.5869651 =
> weight(inStock:F in 30) [SchemaSimilarity], result of:\n1.5869651 =
> score(doc=30,freq=1.0 = termFreq=1.0\n), product of:\n 1.5869651 = idf,
> computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n
>4.0 = docFreq\n21.0 = docCount\n 1.0 = tfNorm, computed as
> (freq * (k1 + 1)) / (freq + k1) from:\n1.0 = termFreq=1.0\n
> 1.2 = parameter k1\n0.0 = parameter b (norms omitted for field)\n",
> "F8V7067-APL-KIT": "\n1.5869651 = sum of:\n 1.5869651 =
> weight(inStock:F in 3) [SchemaSimilarity], result of:\n1.5869651 =
> score(doc=3,freq=1.0 = termFreq=1.0\n), product of:\n 1.5869651 = idf,
> computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n
>4.0 = docFreq\n21.0 = docCount\n 1.0 = tfNorm, computed as
> (freq * (k1 + 1)) / (freq + k1) from:\n1.0 = termFreq=1.0\n
> 1.2 = parameter k1\n0.0 = parameter b (norms omitted for field)\n",
> "GB18030TEST": "\n0.22884157 = sum of:\n 0.22884157 = weight(inStock:T
> in 0) [SchemaSimilarity], result of:\n0.22884157 = score(doc=0,freq=1.0 =
> termFreq=1.0\n), product of:\n 0.22884157 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n17.0 = docFreq\n
>21.0 = docCount\n 1.0 = tfNorm, computed as (freq * (k1 + 1)) /
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n
> 0.0 = parameter b (norms omitted for field)\n",
> "IW-02": "\n1.5869651 = sum of:\n 1.5869651 = weight(inStock:F in 4)
> [SchemaSimilarity], result of:\n1.5869651 = score(doc=4,freq=1.0 =
> termFreq=1.0\n), product of:\n 1.5869651 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n4.0 = docFreq\n
> 21.0 = docCount\n 1.0 = tfNorm, computed as (freq * (k1 + 1)) /
> (freq + k1) from:\n1.0 = termFreq=1.0\n1.2 = parameter k1\n
> 0.0 = parameter b (norms omitted for field)\n",
> "MA147LL/A": "\n0.22884157 = sum of:\n 0.22884157
[GitHub] [lucene-solr] chenkovsky opened a new pull request #833: SOLR-12069: Default operator parameter q.op ignored.
chenkovsky opened a new pull request #833: SOLR-12069: Default operator parameter q.op ignored. URL: https://github.com/apache/lucene-solr/pull/833 Just change one line of code. I have run all tests in org.apache.solr.search. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 185 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/185/
1 tests failed.
FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth
Error Message:
Expected metric minimums for prefix SECURITY./authentication.:
{failMissingCredentials=0, authenticated=2, passThrough=3,
failWrongCredentials=0, requests=5, errors=0}, but got:
{failMissingCredentials=0, authenticated=1, passThrough=3, totalTime=1799649,
failWrongCredentials=0, requestTimes=546, requests=4, errors=0}
Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix
SECURITY./authentication.: {failMissingCredentials=0, authenticated=2,
passThrough=3, failWrongCredentials=0, requests=5, errors=0}, but got:
{failMissingCredentials=0, authenticated=1, passThrough=3, totalTime=1799649,
failWrongCredentials=0, requestTimes=546, requests=4, errors=0}
at
__randomizedtesting.SeedInfo.seed([39FF0721EE8BB2C8:859171334AD831B2]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:131)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:85)
at
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 180 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/180/ No tests ran. Build Log: [...truncated 24869 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2594 links (2120 relative) to 3410 anchors in 259 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure:
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907892#comment-16907892 ] ASF subversion and git services commented on SOLR-13677: Commit 956f61dde9b1ce3fee6b609955d41d0b90c67285 in lucene-solr's branch refs/heads/jira/SOLR-13677_1 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=956f61d ] SOLR-13677: minimize changes > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.3) - Build # 8088 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8088/ Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseSerialGC 14 tests failed. FAILED: org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence Error Message: Software caused connection abort: recv failed Stack Trace: javax.net.ssl.SSLException: Software caused connection abort: recv failed at __randomizedtesting.SeedInfo.seed([2F01E582C06239F3:DA081FF650E5FB6]:0) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215) at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226) at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192) at org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence(TestModelManagerPersistence.java:168) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1422 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1422/ No tests ran. Build Log: [...truncated 24456 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2594 links (2120 relative) to 3411 anchors in 259 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
[jira] [Created] (SOLR-13699) maxChars no longer working as designed on CopyField
Chris Troullis created SOLR-13699: - Summary: maxChars no longer working as designed on CopyField Key: SOLR-13699 URL: https://issues.apache.org/jira/browse/SOLR-13699 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.1.1, 8.2, 8.1, 8.0, 7.7.2, 7.7.1, 7.7, 8.0.1, 7.7.3, 8.1.2 Reporter: Chris Troullis We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars property on a copy field is no longer functioning as designed. Per the most recent documentation it looks like there have been no intentional changes as to the functionality of this property, so I assume this is a bug. In debugging the issue, it looks like the bug was caused by SOLR-12992. In DocumentBuilder where the maxChar limit is applied, it first checks if the value is instanceof String. As of SOLR-12992, string values are now coming in as ByteArrayUtf8CharSequence (unless they are above a certain size as defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, and the maxChar truncation is not being applied. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908336#comment-16908336 ] Mark Miller commented on SOLR-13452: [~ctargett], one thing still left is the doc module! I stubbed it out, but if you have any spare cycles, would love to take you up on the help offer. I can pitch in on the gradle side, but I'm pretty out of the know on the doc stuff and this project is already swallowing me up. Either way, I'll look to tackle it eventually. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908338#comment-16908338 ] Mark Miller commented on SOLR-13452: [~tomoko], ping - probably not a bad time to start looking at support for intellij? I think from that perspective things are in fairly good shape. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 415 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/415/
1 tests failed.
FAILED: org.apache.solr.handler.TestContainerReqHandler.testRuntimeLib
Error Message:
attempt: 9 Mismatch for value : 'requestHandler' in response {
"responseHeader":{ "status":0, "QTime":0}, "metadata":{"version":3},
"runtimeLib":[{ "name":"foo",
"url":"http://localhost:36368/jar3.jar;,
"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922":"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922"}],
"requestHandler":[{"bar":"org.apache.solr.core.RuntimeLibReqHandler"}]}
Stack Trace:
java.lang.AssertionError: attempt: 9 Mismatch for value : 'requestHandler' in
response {
"responseHeader":{
"status":0,
"QTime":0},
"metadata":{"version":3},
"runtimeLib":[{
"name":"foo",
"url":"http://localhost:36368/jar3.jar;,
"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922":"60ec88c2a2e9b409f7afc309273383810a0d07a078b482434eda9674f7e25b8adafa8a67c9913c996cbfb78a7f6ad2b9db26dbd4fe0ca4068f248d5db563f922"}],
"requestHandler":[{"bar":"org.apache.solr.core.RuntimeLibReqHandler"}]}
at
__randomizedtesting.SeedInfo.seed([C05E7BAA7922060F:F3F9EFFE8AB2F7BB]:0)
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.solr.handler.TestContainerReqHandler.assertResponseValues(TestContainerReqHandler.java:106)
at
org.apache.solr.handler.TestContainerReqHandler.testRuntimeLib(TestContainerReqHandler.java:222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Updated] (SOLR-13698) Querying suggester with alias fails
[
https://issues.apache.org/jira/browse/SOLR-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eileen Mosch updated SOLR-13698:
Summary: Querying suggester with alias fails (was: Calling Suggester via
Alias fails)
> Querying suggester with alias fails
> ---
>
> Key: SOLR-13698
> URL: https://issues.apache.org/jira/browse/SOLR-13698
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 8.2, 8.1.1
>Reporter: Eileen Mosch
>Priority: Major
> Attachments: http_suggester_stacktrace.json
>
>
> There's a problem using a multi-collection alias in combination with
> suggester request. We used version 7.3.1 and had no problems, after upgrading
> to version 8.x exceptions are thrown.
> *Details*
> I created an alias called „WORLD“ pointing to six collections.
> {code:java}
> // aliases.json
> {"collection":{
> "AT":"AT.test",
> "BE":"BE.test",
> "DE":"DE.test",
> "FR":"FR.test",
> "LU":"LU.test",
> "NL":"NL.test",
> "WORLD":"AT.test,BE.test,DE.test,FR.test,LU.test,NL.test"}
> }
> {code}
> If I send a {{/suggest}} request using SolrJClient with "WORLD" I get the
> error message: „No live SolrServers available to handle this
> request:[http://[myIP]:8983/solr/WORLD“.
> If I try to call {{/suggest}} via Solr HTTP API, I get „Timeout occured while
> waiting response from server at:
> [http://[myIP]:8983/solr/AT.test_shard1_replica_n1/suggest]“ (see full
> stacktrace attached). The collection name within the error messages differs
> (AT.test... or BE.test... ) but the error information is still the same.
> {code:java}
> // HTTP API Suggester Call
> http://[myIP]:8983/solr/WORLD/suggest?suggest=true=Rue%20Roi%20Albert=streetSuggester=streetSuggesterFuzzy=true
> {code}
> If I use single-collection Aliases (e.g. "AT") everything works fine.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908365#comment-16908365 ] ASF subversion and git services commented on SOLR-13452: Commit 47124b63b02cb7a1f4ce14064b68d098ad9a74b9 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=47124b6 ] SOLR-13452: Work on test run output improvements and removing basic compiler warnings (so they don't clutter up the build output and we don't just hide them) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908367#comment-16908367 ] ASF subversion and git services commented on SOLR-13452: Commit 4914e637d009692a0fa9b3fde6186248831781cd in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4914e63 ] SOLR-13452: Cleanup silly ant output about overriding javadoc task. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908369#comment-16908369 ] ASF subversion and git services commented on SOLR-13452: Commit 863594ae31b7d98ed891322193725029eb173694 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=863594a ] SOLR-13452: Fix a couple of bugs in the license checker. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908368#comment-16908368 ] ASF subversion and git services commented on SOLR-13452: Commit ba6f6bb285e33c4b1ea9b071a7eba97706a59241 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ba6f6bb ] SOLR-13452: Remove more warnings from more modules. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908366#comment-16908366 ] ASF subversion and git services commented on SOLR-13452: Commit 7208a46af27cbb113f7c03445c0a115b3f33785b in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7208a46 ] SOLR-13452: More work on removing compile warnings. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Troullis updated SOLR-13699: -- Description: We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars property on a copy field is no longer functioning as designed, while indexing via SolrJ. Per the most recent documentation it looks like there have been no intentional changes as to the functionality of this property, so I assume this is a bug. In debugging the issue, it looks like the bug was caused by SOLR-12992. In DocumentBuilder where the maxChar limit is applied, it first checks if the value is instanceof String. As of SOLR-12992, string values are now coming in as ByteArrayUtf8CharSequence (unless they are above a certain size as defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, and the maxChar truncation is not being applied. I am currently not sure if this issue is limited to indexing via SolrJ or if it applies to documents indexed via any means was: We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars property on a copy field is no longer functioning as designed, while indexing via SolrJ. Per the most recent documentation it looks like there have been no intentional changes as to the functionality of this property, so I assume this is a bug. In debugging the issue, it looks like the bug was caused by SOLR-12992. In DocumentBuilder where the maxChar limit is applied, it first checks if the value is instanceof String. As of SOLR-12992, string values are now coming in as ByteArrayUtf8CharSequence (unless they are above a certain size as defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, and the maxChar truncation is not being applied. > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Priority: Major > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 268 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/268/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete Error Message: Failed while waiting for active collection Timeout waiting to see state for collection=testcollection :null Live Nodes: [127.0.0.1:34780_solr, 127.0.0.1:40043_solr, 127.0.0.1:45871_solr, 127.0.0.1:46441_solr, 127.0.0.1:49951_solr] Last available state: null Stack Trace: java.lang.RuntimeException: Failed while waiting for active collection Timeout waiting to see state for collection=testcollection :null Live Nodes: [127.0.0.1:34780_solr, 127.0.0.1:40043_solr, 127.0.0.1:45871_solr, 127.0.0.1:46441_solr, 127.0.0.1:49951_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([7899523D88C883F4:DB63FC980F206951]:0) at org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:758) at org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:764) at org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.createCollection(TestCollectionsAPIViaSolrCloudCluster.java:97) at org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
The Gradle train.
https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. Okay, we are at the point where either this thing lands soon and gains some contributors to help finish or it overwhelms me and crashes & burns. That almost sounds negative, but it was actually the plan so far and I'm pretty excited after all this time invested. I need to punt this over to the community though - the final implications and ramifications of moving fully to gradle are just too big for me individually regardless of the time frame. I've done about 95%+ of what I wanted to do before trying to land something - a few more hoops to jump around. We pull in more deps than we should right now, I'll deal with that shortly, and mvn publishing needs work (mostly around solr-server, but dist and publishing both prob need edge work at least). Those are the main things on my mind. There are probably a ton of other little things, but I'm thinking those that are important will rise up quickly and the rest can be handled over time. This will be a large change. Some things will still take time to get up to par with what we have now. Many things will need to be sorted out (jenkins, releases, smoke tester type things, docs, etc). I've also made all the decisions and trade-offs and what not. I'm pretty happy about that, but I'm sure some will want to discuss and debate some choices once things are in their face. I've spent a lot of time in my recent life on this stuff and I'm ready to battle for some of it :) And to be mistaken, ignorant, or convinced of other paths for some other parts of it. I'll only say, every time I go from working with the gradle build back to ant+ivy+mvn, it feels like a big backslide. I'm thinking maybe in September/October? And only on master, hopefully living side by side with ant+ivy+mvn, but the goal would be for that period to be brief. They can't live in complete harmony - someone has to own the dependency view of the world for example, the one that actually gets committed (license, checksums, etc). Otherwise, I've done my best to do this in a way that doesn't break the current build. Will need to inspect that closer before landing though. This is just another heads up. Once we are in a main branch, I'm hoping a few of you will either have to jump in and help this land or we will have to pull it back out I think. Be prepared :) -- - Mark http://about.me/markrmiller
Re: The Gradle train.
Go for it! I’ve been amazed by the effort you’ve put in it, and it’ll be good for some of the load to be distributed. Of course I’ll need to learn new tricks (something about old dogs in here)….. Erick > On Aug 15, 2019, at 5:23 PM, Mark Miller wrote: > > https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the > lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > > Okay, we are at the point where either this thing lands soon and gains some > contributors to help finish or it overwhelms me and crashes & burns. That > almost sounds negative, but it was actually the plan so far and I'm pretty > excited after all this time invested. I need to punt this over to the > community though - the final implications and ramifications of moving fully > to gradle are just too big for me individually regardless of the time frame. > > I've done about 95%+ of what I wanted to do before trying to land something - > a few more hoops to jump around. We pull in more deps than we should right > now, I'll deal with that shortly, and mvn publishing needs work (mostly > around solr-server, but dist and publishing both prob need edge work at > least). Those are the main things on my mind. There are probably a ton of > other little things, but I'm thinking those that are important will rise up > quickly and the rest can be handled over time. > > This will be a large change. Some things will still take time to get up to > par with what we have now. Many things will need to be sorted out (jenkins, > releases, smoke tester type things, docs, etc). > > I've also made all the decisions and trade-offs and what not. I'm pretty > happy about that, but I'm sure some will want to discuss and debate some > choices once things are in their face. I've spent a lot of time in my recent > life on this stuff and I'm ready to battle for some of it :) And to be > mistaken, ignorant, or convinced of other paths for some other parts of it. > I'll only say, every time I go from working with the gradle build back to > ant+ivy+mvn, it feels like a big backslide. > > I'm thinking maybe in September/October? And only on master, hopefully living > side by side with ant+ivy+mvn, but the goal would be for that period to be > brief. They can't live in complete harmony - someone has to own the > dependency view of the world for example, the one that actually gets > committed (license, checksums, etc). Otherwise, I've done my best to do this > in a way that doesn't break the current build. Will need to inspect that > closer before landing though. > > This is just another heads up. Once we are in a main branch, I'm hoping a few > of you will either have to jump in and help this land or we will have to pull > it back out I think. Be prepared :) > > -- > - Mark > > http://about.me/markrmiller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 1024 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1024/ Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom Error Message: Error from server at http://127.0.0.1:35431/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection: Error from server at null: Expected mime type application/octet-stream but got text/html.Error 500 Server Error HTTP ERROR 500 Problem accessing /solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard1_replica_n1/select. Reason: Server ErrorCaused by:java.lang.AssertionError at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849) at java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014) at java.util.HashMap.putVal(HashMap.java:638) at java.util.HashMap.put(HashMap.java:612) at org.apache.solr.search.LRUCache.put(LRUCache.java:196) at org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568) at org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2592) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:311) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917) at java.lang.Thread.run(Thread.java:748) http://eclipse.org/jetty;>Powered by Jetty:// 9.4.19.v20190610 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35431/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection: Error from server at null: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR 500 Problem accessing /solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard1_replica_n1/select. Reason: Server ErrorCaused by:java.lang.AssertionError at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849) at java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014) at java.util.HashMap.putVal(HashMap.java:638) at java.util.HashMap.put(HashMap.java:612) at org.apache.solr.search.LRUCache.put(LRUCache.java:196) at org.apache.solr.search.SolrCacheHolder.put(SolrCacheHolder.java:46) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568) at
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908422#comment-16908422 ] Chris Troullis commented on SOLR-13699: --- [~erickerickson] So after looking through the CopyFieldTest unit tests, I found that we are already testing the maxChars functionality via the testCopyFieldFunctionality() test, and the maxChars functionality is working properly when the test runs! After further digging it seems that the issue only occurs when docs are indexed in Binary format, using the JavaBinCodec, as this is where there change was made to read strings as a ByteArrayUtf8CharSequence instead of a string. It appears that the test framework indexes docs in XML format, which does not use the JavaBinCodec, so the fields are read as strings, and the maxChars works as designed. So, in other words, it's still an issue, but looks like it only effects docs indexed in Binary format. Since it looks like the test framework only supports indexing in XML format (although I didn't look that hard), do you have any suggestions on how to properly unit test this? > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Priority: Major > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Troullis updated SOLR-13699: -- Description: We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars property on a copy field is no longer functioning as designed, while indexing via SolrJ. Per the most recent documentation it looks like there have been no intentional changes as to the functionality of this property, so I assume this is a bug. In debugging the issue, it looks like the bug was caused by SOLR-12992. In DocumentBuilder where the maxChar limit is applied, it first checks if the value is instanceof String. As of SOLR-12992, string values are now coming in as ByteArrayUtf8CharSequence (unless they are above a certain size as defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, and the maxChar truncation is not being applied. was: We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars property on a copy field is no longer functioning as designed. Per the most recent documentation it looks like there have been no intentional changes as to the functionality of this property, so I assume this is a bug. In debugging the issue, it looks like the bug was caused by SOLR-12992. In DocumentBuilder where the maxChar limit is applied, it first checks if the value is instanceof String. As of SOLR-12992, string values are now coming in as ByteArrayUtf8CharSequence (unless they are above a certain size as defined by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String check, and the maxChar truncation is not being applied. > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Priority: Major > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-13699: - Assignee: Erick Erickson > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908468#comment-16908468 ] ASF subversion and git services commented on SOLR-13452: Commit 81132db7ca28faa2cf09b94c27686e1139c88a9e in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=81132db ] SOLR-13452: Remove almost all transitive dep disables. Will cleanup the extra deps that come in now later. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908469#comment-16908469 ] ASF subversion and git services commented on SOLR-13452: Commit 23d06dadb206f8d5b5fe95d352eec77233c51647 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=23d06da ] SOLR-13452: Start including more than the default artifacts in solr-server module dist packages and handle start.jar. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908386#comment-16908386 ] Chris Troullis commented on SOLR-13699: --- Created after discussion with [~erickerickson] on the mailing list. I think I have a fix working, just finishing testing and writing a unit test, then I will attach my patch. > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Priority: Major > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed. Per the most > recent documentation it looks like there have been no intentional changes as > to the functionality of this property, so I assume this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified
Hoss Man created SOLR-13700:
---
Summary: Race condition in initializing metrics for new security
plugins when security.json is modified
Key: SOLR-13700
URL: https://issues.apache.org/jira/browse/SOLR-13700
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
When new security plugins are initialized due to remote API requetss, there is
a delay between "registering" the new plugins for use in methods like
{{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's
volatile {{this.authenticationPlugin}} variable) and when the
{{initializeMetrics(..)}} method is called on these plugins, so that they
continue to use the existing {{Metric}} instances as the plugins they are
replacing.
Because these security plugins maintain local refrences to these Metrics (and
don't "get" them from the MetricRegisty everytime they need to {{inc()}} them)
this means that there is short race condition situation such that during the
window of time after a new plugin instance is put into use, but before
{{initializeMetrics(..)}} is called on them, at these plugins are responsible
for accepting/rejecting requests, and decisions in {{Metric}} instances that
are not registered and subsequently get thrown away (and GCed) once the
CoreContainer gets around to calling {{initializeMetrics(..)}} (and the plugin
starts using the pre-existing metric objects)
This has some noticible impacts on auth tests on CPU constrained jenkins
machines (even after putting in place SOLR-13464 work arounds) that make
assertions about the metrics recorded.
In real world situations, the impact of this bug on users is minor: for a few
micro/milli-seconds, requests may come in w/o being counted in the auth metrics
-- which may also result in descrepencies between the auth metrics totals and
the overall request metrics.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8648) TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)
[ https://issues.apache.org/jira/browse/LUCENE-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908669#comment-16908669 ] Chongchen Chen commented on LUCENE-8648: I checkout the version before 2e468abecc. But still cannot reproduce. :( > TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?) > -- > > Key: LUCENE-8648 > URL: https://issues.apache.org/jira/browse/LUCENE-8648 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: master (9.0) >Reporter: Dawid Weiss >Priority: Major > > I didn't have time to investigate but this seed hangs for me on this test: > -Dtests.seed=A586F88535C84727 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3566 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3566/ 2 tests failed. FAILED: org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat Error Message: re-indexing warning not found Stack Trace: java.lang.AssertionError: re-indexing warning not found at __randomizedtesting.SeedInfo.seed([7BF195631B314E4A:B0436CA7BF9E73C]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat(SystemCollectionCompatTest.java:206) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom Error Message: Error from server at http://127.0.0.1:42409/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR 500 Problem accessing
Re: The Gradle train.
I'm +1. Gradle can be annoying like hell, but it's much faster and flexible than any other build tool I've tried. D. On Thu, Aug 15, 2019 at 11:24 PM Mark Miller wrote: > > https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the > lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > > Okay, we are at the point where either this thing lands soon and gains some > contributors to help finish or it overwhelms me and crashes & burns. That > almost sounds negative, but it was actually the plan so far and I'm pretty > excited after all this time invested. I need to punt this over to the > community though - the final implications and ramifications of moving fully > to gradle are just too big for me individually regardless of the time frame. > > I've done about 95%+ of what I wanted to do before trying to land something - > a few more hoops to jump around. We pull in more deps than we should right > now, I'll deal with that shortly, and mvn publishing needs work (mostly > around solr-server, but dist and publishing both prob need edge work at > least). Those are the main things on my mind. There are probably a ton of > other little things, but I'm thinking those that are important will rise up > quickly and the rest can be handled over time. > > This will be a large change. Some things will still take time to get up to > par with what we have now. Many things will need to be sorted out (jenkins, > releases, smoke tester type things, docs, etc). > > I've also made all the decisions and trade-offs and what not. I'm pretty > happy about that, but I'm sure some will want to discuss and debate some > choices once things are in their face. I've spent a lot of time in my recent > life on this stuff and I'm ready to battle for some of it :) And to be > mistaken, ignorant, or convinced of other paths for some other parts of it. > I'll only say, every time I go from working with the gradle build back to > ant+ivy+mvn, it feels like a big backslide. > > I'm thinking maybe in September/October? And only on master, hopefully living > side by side with ant+ivy+mvn, but the goal would be for that period to be > brief. They can't live in complete harmony - someone has to own the > dependency view of the world for example, the one that actually gets > committed (license, checksums, etc). Otherwise, I've done my best to do this > in a way that doesn't break the current build. Will need to inspect that > closer before landing though. > > This is just another heads up. Once we are in a main branch, I'm hoping a few > of you will either have to jump in and help this land or we will have to pull > it back out I think. Be prepared :) > > -- > - Mark > > http://about.me/markrmiller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 402 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/402/ Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud Error Message: IOException occurred when talking to server at: https://127.0.0.1:57981/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occurred when talking to server at: https://127.0.0.1:57981/solr at __randomizedtesting.SeedInfo.seed([77EED741CBFE36A9:A6E925C46FF1BD9B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:87) at org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:79) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[jira] [Updated] (SOLR-13700) Race condition in initializing metrics for new security plugins when security.json is modified
[
https://issues.apache.org/jira/browse/SOLR-13700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13700:
Assignee: Hoss Man
Attachment: SOLR-13700.patch
Status: Open (was: Open)
Attaching a patch to address this, one nocommit regarding something that makes
no sense to me...
[~ab] - can you please review and sanity check:
# that my understanding is correct, and that it's "safe" (and more correct) for
the "old" and "new" instances of these plugins to be using the same Metric
instances before the "new" plugin replaces the old one
# the nocommit comments -- unless i'm missing something
{{reloadSecurityProperties()}} has no business calling
{{pkiAuthenticationPlugin.initializeMetrics(...)}}, because
{{pkiAuthenticationPlugin}} can never change as a result of reloading the
security.json ... so {{pkiAuthenticationPlugin.initializeMetrics(...)}} should
be called exactly once (and only once) for it's entire lifecycle ... ideally in
{{CoreContainer.load()}} immediately after calling {{pkiAuthenticationPlugin =
new PKIAuthenticationPlugin...)}}
> Race condition in initializing metrics for new security plugins when
> security.json is modified
> --
>
> Key: SOLR-13700
> URL: https://issues.apache.org/jira/browse/SOLR-13700
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13700.patch
>
>
> When new security plugins are initialized due to remote API requetss, there
> is a delay between "registering" the new plugins for use in methods like
> {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's
> volatile {{this.authenticationPlugin}} variable) and when the
> {{initializeMetrics(..)}} method is called on these plugins, so that they
> continue to use the existing {{Metric}} instances as the plugins they are
> replacing.
> Because these security plugins maintain local refrences to these Metrics (and
> don't "get" them from the MetricRegisty everytime they need to {{inc()}}
> them) this means that there is short race condition situation such that
> during the window of time after a new plugin instance is put into use, but
> before {{initializeMetrics(..)}} is called on them, at these plugins are
> responsible for accepting/rejecting requests, and decisions in {{Metric}}
> instances that are not registered and subsequently get thrown away (and GCed)
> once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and
> the plugin starts using the pre-existing metric objects)
>
> This has some noticible impacts on auth tests on CPU constrained jenkins
> machines (even after putting in place SOLR-13464 work arounds) that make
> assertions about the metrics recorded.
> In real world situations, the impact of this bug on users is minor: for a few
> micro/milli-seconds, requests may come in w/o being counted in the auth
> metrics -- which may also result in descrepencies between the auth metrics
> totals and the overall request metrics.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
[
https://issues.apache.org/jira/browse/SOLR-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908689#comment-16908689
]
Gus Heck commented on SOLR-13696:
-
Thx for the write up and suggestions. I will look as soon as I can, but this
weekend is not looking likely due to weekend commitments & visiting family.
Possibly by Monday or Tuesday I'll just declare a solr day (or half day) for
myself, there are several things I want to look at that keep getting pushed.
Routed Alias tests in general do seem to run up against the timing sorts of
issues frequently. I've had no end of trouble with various bits of code that
need to wait for a collection to be available, or a zookeeper related change to
be visible (or both) etc. The existing wait methods for that stuff all seem to
fail some small fraction of a percent of the time... for example SOLR-13059...
which is among the things on my list to go back and check the status of and see
if it's improved or if anything I've learned since makes the solution more
obvious...
> DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest
> failures due commitWithin/openSearcher delays
>
>
> Key: SOLR-13696
> URL: https://issues.apache.org/jira/browse/SOLR-13696
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Gus Heck
>Priority: Major
> Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt
>
>
> Recent jenkins failure...
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
> {noformat}
> Stack Trace:
> java.lang.AssertionError: expected:<16> but was:<15>
> at
> __randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
> )
> at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Digging into the logs, the problem appears to be in the way the test
> verifies/assumes docs have been committed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13059) TimeRoutedAliasUpdateProcessorTest rarely fails to see collection just created
[
https://issues.apache.org/jira/browse/SOLR-13059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck reassigned SOLR-13059:
---
Assignee: Gus Heck
> TimeRoutedAliasUpdateProcessorTest rarely fails to see collection just created
> --
>
> Key: SOLR-13059
> URL: https://issues.apache.org/jira/browse/SOLR-13059
> Project: Solr
> Issue Type: Bug
> Components: Tests
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>
> This issue is for tracking down and fixing this stack trace observed during
> SOLR-13051:
> {code:java}
> [junit4] ERROR 11.2s | TimeRoutedAliasUpdateProcessorTest.testSliceRouting <<<
> [junit4] > Throwable #1:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException:
> Error from server at http://127.0.0.1:32891/solr: no core retrieved for
> testSliceRouting
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([D9B32625DD304967:E823AAC97966B64E]:0)
> [junit4] > at
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:829)
> [junit4] > at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
> [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.sendRequest(CloudSolrClient.java:1110){code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8648) TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?)
[ https://issues.apache.org/jira/browse/LUCENE-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908702#comment-16908702 ] Dawid Weiss commented on LUCENE-8648: - Well, that's strange. I can reproduce it with full reliability on different machines. I can't work on it now though. Let's leave the issue open. > TestIndexWriterDelete.testUpdatesOnDiskFull hangs indefinitely (?) > -- > > Key: LUCENE-8648 > URL: https://issues.apache.org/jira/browse/LUCENE-8648 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: master (9.0) >Reporter: Dawid Weiss >Priority: Major > > I didn't have time to investigate but this seed hangs for me on this test: > -Dtests.seed=A586F88535C84727 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests
Hoss Man created SOLR-13701:
---
Summary: JWTAuthPlugin calls authenticationFailure (which calls
HttpServletResponsesendError) before updating metrics - breaks tests
Key: SOLR-13701
URL: https://issues.apache.org/jira/browse/SOLR-13701
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
The way JWTAuthPlugin is currently implemented, any failures are sent to the
remote client (via {{authenticationFailure(...)}} which calls
{{HttpServletResponsesendError(...)}}) *before*
{{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics (like
{{numErrors}} and {{numWrongCredentials}})
This causes a race condition in tests where test threads can:
* see an error response/Exception before the server thread has updated metrics
(like {{numErrors}} and {{numWrongCredentials}})
* call white box methods like
{{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected
metrics
...all before the server thread has ever gotten around to being able to update
the metrics in question.
{{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some
{{"First metrics count assert failed, pausing 2s before re-attempt"}} evidently
to try and work around this bug, but it's still no garuntee that the server
thread will be scheduled before the retry happens.
We can/should just fix JWTAuthPlugin to ensure the metrics are updated before
{{authenticationFailure(...)}} is called, and then remove the "pausing 2s
before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug fix,
and the existing work around for SOLR-13464, there should be absolutely no
reason to "retry" reading hte metrics.
(NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method that
also calls {{HttpServletResponse.sendError(...)}} - but it already (correctly)
updates the error/failure metrics *before* calling that method.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13701) JWTAuthPlugin calls authenticationFailure (which calls HttpServletResponsesendError) before updating metrics - breaks tests
[
https://issues.apache.org/jira/browse/SOLR-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13701:
Attachment: SOLR-13701.patch
Status: Open (was: Open)
Attaching patch that addressess this.
I also updates the existing code paths that propogate the request via
{{filterChain.doFilter(...)}} to ensure that the associated metrics (
{{numPassThrough}} and/or {{numAuthenticated}} ) are updated *before*
{{filterChain.doFilter(...)}} is called, so that they are correct even if a
subsequent filter (or ultimately, the SolrCore/RequestHandler) encounters an
error or otherwise rejects the request.
[~janhoy] - would appreciate if you could review.
> JWTAuthPlugin calls authenticationFailure (which calls
> HttpServletResponsesendError) before updating metrics - breaks tests
> ---
>
> Key: SOLR-13701
> URL: https://issues.apache.org/jira/browse/SOLR-13701
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13701.patch
>
>
> The way JWTAuthPlugin is currently implemented, any failures are sent to the
> remote client (via {{authenticationFailure(...)}} which calls
> {{HttpServletResponsesendError(...)}}) *before*
> {{JWTAuthPlugin.doAuthenticate(...)}} has a chance to update it's metrics
> (like {{numErrors}} and {{numWrongCredentials}})
> This causes a race condition in tests where test threads can:
> * see an error response/Exception before the server thread has updated
> metrics (like {{numErrors}} and {{numWrongCredentials}})
> * call white box methods like
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} to assert expected
> metrics
> ...all before the server thread has ever gotten around to being able to
> update the metrics in question.
> {{SolrCloudAuthTestCase.assertAuthMetricsMinimums(...)}} currently has some
> {{"First metrics count assert failed, pausing 2s before re-attempt"}}
> evidently to try and work around this bug, but it's still no garuntee that
> the server thread will be scheduled before the retry happens.
> We can/should just fix JWTAuthPlugin to ensure the metrics are updated before
> {{authenticationFailure(...)}} is called, and then remove the "pausing 2s
> before re-attempt" logic from {{SolrCloudAuthTestCase}} - between this bug
> fix, and the existing work around for SOLR-13464, there should be absolutely
> no reason to "retry" reading hte metrics.
> (NOTE: BasicAuthPlugin has a similar {{authenticationFailure(...)}} method
> that also calls {{HttpServletResponse.sendError(...)}} - but it already
> (correctly) updates the error/failure metrics *before* calling that method.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1931 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1931/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-12.0.1) - Build # 5293 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5293/ Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime Error Message: took over 10 seconds after collection creation to update aliases Stack Trace: java.lang.AssertionError: took over 10 seconds after collection creation to update aliases at __randomizedtesting.SeedInfo.seed([6E89C34E7B1D0825:69828C4D44EE59CD]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:77) at org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:480) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) Build Log: [...truncated 2043 lines...] [junit4] JVM J1: stderr was not empty, see:
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 182 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/182/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for
collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/24)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"https://127.0.0.1:33261/solr;,
"node_name":"127.0.0.1:33261_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"https://127.0.0.1:46348/solr;,
"node_name":"127.0.0.1:46348_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node7":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"https://127.0.0.1:33261/solr;,
"node_name":"127.0.0.1:33261_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"https://127.0.0.1:46348/solr;,
"node_name":"127.0.0.1:46348_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node8/data/tlog",
"core":"testSimple2_shard2_replica_n6",
"shared_storage":"true", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"true", "nrtReplicas":"2",
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:44135_solr, 127.0.0.1:46348_solr]
Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/24)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"https://127.0.0.1:33261/solr;,
"node_name":"127.0.0.1:33261_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"https://127.0.0.1:46348/solr;,
"node_name":"127.0.0.1:46348_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node7":{
"dataDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"https://127.0.0.1:33261/solr;,
"node_name":"127.0.0.1:33261_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://lucene2-us-west.apache.org:34284/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
