[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4770 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4770/ Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 46256 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:536: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:90: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build.xml:135: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build.xml:470: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\common-build.xml:2584: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\build\docs\changes\jiraVersionList.json Total time: 92 minutes 27 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574208#comment-14574208 ] Alan Woodward commented on SOLR-7613: - I've been playing around with this a bit, and have come up with the following solution: the extra properties are loaded by the SolrResourceLoader, rather than in CoreDescriptor, which means that it's automatically loaded from the 'correct' place (and will allow overriding and editing when SOLR-7570 is in). Properties are only actually used by the resource loader, so there's no particular need for them to be available via CoreDescriptor anyway. I should have a patch to upload early next week. solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to reload the properties when the file changes (or via a core reload). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12768 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12768/ Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 46306 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:90: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:135: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:470: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2584: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/docs/changes/jiraVersionList.json Total time: 58 minutes 18 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Early Access builds for JDK 9 b66 and JDK 8u60 b18 are available on java.net
Hi Uwe Dawid, Early Access build for JDK 8u60 b18 http://jdk8.java.net/download.html is available on java.net, summary of changes are listed here. http://www.java.net/download/jdk8u60/changes/jdk8u60-b18.html As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b66 https://jdk9.java.net/download/ is available on java.net, summary of changes are listed here http://www.java.net/download/jdk9/changes/jdk9-b66.html. The JDK 9 schedule of record is available on the JDK 9 Project page: http://openjdk.java.net/projects/jdk9 At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can find a (preliminary) list of other changes that might affect your project's code in JDK 9, and other things to consider when testing with JDK 9. I'd be curious to know if there is anything on that list you'd consider to have an effect on your project. Please keep in mind that as JEPs and others changes are integrated into (or out of) JDK 9, the list will change over time. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
[jira] [Commented] (SOLR-5882) Support scoreMode parameter for BlockJoinParentQParser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574169#comment-14574169
]
Alessandro Benedetti commented on SOLR-5882:
Hi,
Is there any idea when this patch will be included in Solr Code Base ?
I find it to be a very interesting aspect to complete the Join feature!
Cheers
Support scoreMode parameter for BlockJoinParentQParser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Attachments: SOLR-5882.patch
Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
None:
{code:borderStyle=solid}
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery(query, getFilter(parentList),
ScoreMode.None);
}
{code}
Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
false:
{code:borderStyle=solid}
protected Query createQuery(Query parentListQuery, Query query) {
return new ToChildBlockJoinQuery(query, getFilter(parentListQuery),
false);
}
{code}
I propose to have ability to configure this scoring options via query syntax.
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent scoreMode=None|Avg|Max|Total}
{code}
For child query:
{code:borderStyle=solid}
{!child of=type:parent doScores=true|false}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12943 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12943/ Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 45665 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:90: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:135: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:470: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2500: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/changes/jiraVersionList.json Total time: 53 minutes 12 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6527) TermWeight should not load norms when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574341#comment-14574341 ] Robert Muir commented on LUCENE-6527: - Should we pull this out and for consistency use in other places like PhraseWeight/SpanWeight/etc? TermWeight should not load norms when needsScores is false -- Key: LUCENE-6527 URL: https://issues.apache.org/jira/browse/LUCENE-6527 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6527.patch TermWeight currently loads norms all the time, even when needsScores is false. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6527) TermWeight should not load norms when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574403#comment-14574403 ] Uwe Schindler commented on LUCENE-6527: --- I like the non-scoring SimScorer :-) We should indeed factor it out as a utility class, so it can be reused by other queries, too. TermWeight should not load norms when needsScores is false -- Key: LUCENE-6527 URL: https://issues.apache.org/jira/browse/LUCENE-6527 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6527.patch TermWeight currently loads norms all the time, even when needsScores is false. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton updated SOLR-7640:
Description:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${{solr.solr.home}} is replaced with empty value (or wit default if
we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
was:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${solr.solr.home} is replaced with empty value (or wit default if
we specify it)
{quote}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{quote}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
[JENKINS] Lucene-Solr-NightlyTests-5.2 - Build # 11 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.2/11/ All tests passed Build Log: [...truncated 12090 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/build/solr-core/test/J2/temp/solr.cloud.CollectionsAPIDistributedZkTest 8EE5315ABA299BC9-001/init-core-data-001 [junit4] 2 1343166 T10984 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (false) and clientAuth (true) [junit4] 2 1343166 T10984 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: /u_mbs/zf [junit4] 2 1343170 T10984 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 2 1343171 T10985 oasc.ZkTestServer$2$1.setClientPort client port:0.0.0.0/0.0.0.0:0 [junit4] 2 1343171 T10985 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2 1343271 T10984 oasc.ZkTestServer.run start zk server on port:46883 [junit4] 2 1343271 T10984 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 1343272 T10984 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 1343274 T10992 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@70b7f642 name:ZooKeeperConnection Watcher:127.0.0.1:46883 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1343275 T10984 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 1343275 T10984 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 1343275 T10984 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2 1343278 T10984 oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default ZkCredentialsProvider [junit4] 2 1343278 T10984 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2 1343279 T10995 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@7d7c7c82 name:ZooKeeperConnection Watcher:127.0.0.1:46883/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 1343280 T10984 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2 1343280 T10984 oascc.SolrZkClient.createZkACLProvider Using default ZkACLProvider [junit4] 2 1343280 T10984 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2 1343282 T10984 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2 1343284 T10984 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2 1343285 T10984 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2 1343287 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2 1343287 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2 1343290 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [junit4] 2 1343290 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2 1343292 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2 1343292 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2 1343294 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2 1343294 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/stopwords.txt [junit4] 2 1343296 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/protwords.txt to /configs/conf1/protwords.txt [junit4] 2 1343296 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/protwords.txt [junit4] 2 1343298 T10984 oasc.AbstractZkTestCase.putConfig put /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.2/solr/core/src/test-files/solr/collection1/conf/currency.xml to /configs/conf1/currency.xml [junit4] 2 1343298 T10984 oascc.SolrZkClient.makePath makePath: /configs/conf1/currency.xml [junit4] 2 1343300 T10984
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_45) - Build # 4771 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4771/ Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseG1GC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([D98080F1642CA4E8]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=9479, name=searcherExecutor-4485-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=9479, name=searcherExecutor-4485-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([D98080F1642CA4E8]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=9479,
[jira] [Updated] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton updated SOLR-7640:
Description:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result {code}${solr.solr.home}{code} is replaced with empty value (or wit
default if we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
{code}${solr.solr.home}{code}, but it i's empty (but it works in config files)
was:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${{solr.solr.home}} is replaced with empty value (or wit default if
we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
[jira] [Commented] (LUCENE-6526) Make AssertingWeight check that scores are not computed when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574413#comment-14574413 ] ASF subversion and git services commented on LUCENE-6526: - Commit 1683734 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1683734 ] LUCENE-6526: Asserting(Query|Weight|Scorer) now ensure scores are not computed if they are not needed. Make AssertingWeight check that scores are not computed when needsScores is false - Key: LUCENE-6526 URL: https://issues.apache.org/jira/browse/LUCENE-6526 Project: Lucene - Core Issue Type: Test Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6526.patch Today nothing prevents you from calling score() if you don't need scores. But we could make AssertingWeight check it in order to make sure that we do not waste resources computing something we don't need. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2386 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2386/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.ZkControllerTest: 1) Thread[id=10795, name=OverseerStateUpdate-93946417128144899-127.0.0.1:8983_solr-n_00, state=TIMED_WAITING, group=Overseer state updater.] at java.lang.Object.wait(Native Method) at org.apache.solr.cloud.DistributedQueue$LatchWatcher.await(DistributedQueue.java:276) at org.apache.solr.cloud.DistributedQueue.getChildren(DistributedQueue.java:320) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:594) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:572) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:190) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.ZkControllerTest: 1) Thread[id=10795, name=OverseerStateUpdate-93946417128144899-127.0.0.1:8983_solr-n_00, state=TIMED_WAITING, group=Overseer state updater.] at java.lang.Object.wait(Native Method) at org.apache.solr.cloud.DistributedQueue$LatchWatcher.await(DistributedQueue.java:276) at org.apache.solr.cloud.DistributedQueue.getChildren(DistributedQueue.java:320) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:594) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:572) at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:190) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([CB8C4132A62525]:0) Build Log: [...truncated 10220 lines...] [junit4] Suite: org.apache.solr.cloud.ZkControllerTest [junit4] 2 Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J1/temp/solr.cloud.ZkControllerTest CB8C4132A62525-001/init-core-data-001 [junit4] 2 2116074 INFO (SUITE-ZkControllerTest-seed#[CB8C4132A62525]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2 2116077 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.SolrTestCaseJ4 ###Starting testReadConfigName [junit4] 2 2116077 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 2116079 INFO (Thread-4141) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 2116079 INFO (Thread-4141) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 2116180 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.ZkTestServer start zk server on port:49876 [junit4] 2 2116180 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 2116182 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 2116196 INFO (zkCallback-1302-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@e4970ce name:ZooKeeperConnection Watcher:127.0.0.1:49876 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 2116197 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 2116197 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 2116200 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 2116202 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 2116205 INFO (zkCallback-1303-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@2e210615 name:ZooKeeperConnection Watcher:127.0.0.1:49876 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 2116206 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 2116206 INFO (TEST-ZkControllerTest.testReadConfigName-seed#[CB8C4132A62525]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 2116206 INFO
[jira] [Resolved] (LUCENE-6526) Make AssertingWeight check that scores are not computed when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6526. -- Resolution: Fixed Fix Version/s: 5.3 Trunk Make AssertingWeight check that scores are not computed when needsScores is false - Key: LUCENE-6526 URL: https://issues.apache.org/jira/browse/LUCENE-6526 Project: Lucene - Core Issue Type: Test Reporter: Adrien Grand Assignee: Adrien Grand Fix For: Trunk, 5.3 Attachments: LUCENE-6526.patch Today nothing prevents you from calling score() if you don't need scores. But we could make AssertingWeight check it in order to make sure that we do not waste resources computing something we don't need. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6526) Make AssertingWeight check that scores are not computed when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574446#comment-14574446 ] ASF subversion and git services commented on LUCENE-6526: - Commit 1683745 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1683745 ] LUCENE-6526: Asserting(Query|Weight|Scorer) now ensure scores are not computed if they are not needed. Make AssertingWeight check that scores are not computed when needsScores is false - Key: LUCENE-6526 URL: https://issues.apache.org/jira/browse/LUCENE-6526 Project: Lucene - Core Issue Type: Test Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6526.patch Today nothing prevents you from calling score() if you don't need scores. But we could make AssertingWeight check it in order to make sure that we do not waste resources computing something we don't need. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3719) Add instant search capability to example/files /browse
[ https://issues.apache.org/jira/browse/SOLR-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esther Quansah updated SOLR-3719: - Attachment: SOLR-3719.patch Awesome idea, Erik! Definitely one we should consider after suggest is implemented. With this small patch - updated JS to fix tag cloud styling during instasearch, attached filter/sort to instasearch. Now onto suggest!! Add instant search capability to example/files /browse Key: SOLR-3719 URL: https://issues.apache.org/jira/browse/SOLR-3719 Project: Solr Issue Type: New Feature Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: Trunk, 5.3 Attachments: SOLR-3719.patch, SOLR-3719.patch, SOLR-3719.patch Once upon a time I tinkered with this in a personal github fork https://github.com/erikhatcher/lucene-solr/commits/instant_search/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6527) TermWeight should not load norms when needsScores is false
[
https://issues.apache.org/jira/browse/LUCENE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-6527:
-
Attachment: LUCENE-6527.patch
Here is a new patch that fixes all queries. I wanted to make it impossible to
forget to apply this optimization so the way the patch works is that
IndexSearcher.getSimilarity now takes a {{boolean needsScores}} parameter too
and returns a dummy similarity when scores are not needed. This forces all
queries that need to work with a Similarity to propagate {{needsScores}} to
index searcher to make sure we do not load eg. norms when scores are not needed.
TermWeight should not load norms when needsScores is false
--
Key: LUCENE-6527
URL: https://issues.apache.org/jira/browse/LUCENE-6527
Project: Lucene - Core
Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Attachments: LUCENE-6527.patch, LUCENE-6527.patch
TermWeight currently loads norms all the time, even when needsScores is false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6527) TermWeight should not load norms when needsScores is false
[
https://issues.apache.org/jira/browse/LUCENE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574479#comment-14574479
]
Alan Woodward commented on LUCENE-6527:
---
For SpanWeight, you don't need to pass needsScores back down to the
constructor, as if the TermContexts map is null then you know scores are not
required. So you can just call {{IndexSearcher.getSimilarity(termContexts !=
null)}}.
TermWeight should not load norms when needsScores is false
--
Key: LUCENE-6527
URL: https://issues.apache.org/jira/browse/LUCENE-6527
Project: Lucene - Core
Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Attachments: LUCENE-6527.patch, LUCENE-6527.patch
TermWeight currently loads norms all the time, even when needsScores is false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6526) Make AssertingWeight check that scores are not computed when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1457#comment-1457 ] ASF subversion and git services commented on LUCENE-6526: - Commit 1683744 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1683744 ] LUCENE-6526: Revert some changes that were committed by mistake. Make AssertingWeight check that scores are not computed when needsScores is false - Key: LUCENE-6526 URL: https://issues.apache.org/jira/browse/LUCENE-6526 Project: Lucene - Core Issue Type: Test Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6526.patch Today nothing prevents you from calling score() if you don't need scores. But we could make AssertingWeight check it in order to make sure that we do not waste resources computing something we don't need. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5954) Store lucene version in segment_N
[ https://issues.apache.org/jira/browse/LUCENE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574480#comment-14574480 ] Michael McCandless commented on LUCENE-5954: bq. It seems weird to have two ways of comparing versions. Good point, I'll remove the compareTo and just use the existing onOrAfter. bq. Is there somewhere we could have a more direct test than deletion policy tests? I'll try to make a more direct test (TestSegmentInfos)... bq. We dont technically need to change file formats to implement this, it could be computed from the segments on read in the 4.0-5.2 case? That's what I do in the patch ... if SIS was written by = 5.3, I pull the min version that we wrote into the header (and throw IndexTooOldExc if it's too old), else I re-compute it on load. Store lucene version in segment_N - Key: LUCENE-5954 URL: https://issues.apache.org/jira/browse/LUCENE-5954 Project: Lucene - Core Issue Type: Bug Reporter: Ryan Ernst Assignee: Michael McCandless Attachments: LUCENE-5954.patch It would be nice to have the version of lucene that wrote segments_N, so that we can use this to determine which major version an index was written with (for upgrading across major versions). I think this could be squeezed in just after the segments_N header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (32bit/ibm-j9-jdk7) - Build # 12772 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12772/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
No tests ran.
Build Log:
[...truncated 308 lines...]
ERROR: Publisher 'Publish JUnit test result report' failed: No test report
files were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6524) Create an IndexWriter from an already opened NRT or non-NRT reader
[ https://issues.apache.org/jira/browse/LUCENE-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574530#comment-14574530 ] Michael McCandless commented on LUCENE-6524: bq. This really needs to be a new method if added at all. Wait: the only thing I'm adding here is a new constructor for IndexWriter. I'm not touching IndexWriter.rollback ... Maybe I should not have used the term rollback in that use case: it is a loaded term! Create an IndexWriter from an already opened NRT or non-NRT reader -- Key: LUCENE-6524 URL: https://issues.apache.org/jira/browse/LUCENE-6524 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.3 Attachments: LUCENE-6524.patch I'd like to add a new ctor to IndexWriter, letting you start from an already opened NRT or non-NRT DirectoryReader. I think this is a long missing API in Lucene today, and we've talked in the past about different ways to fix it e.g. factoring out a shared reader pool between writer and reader. One use-case, which I hit in LUCENE-5376: if you have a read-only index, so you've opened a non-NRT DirectoryReader to search it, and then you want to upgrade to a read/write index, we don't handle that very gracefully now because you are forced to open 2X the SegmentReaders. But with this API, IW populates its reader pool with the incoming SegmentReaders so they are shared on any subsequent NRT reopens / segment merging / deletes applying, etc. Another (more expert) use case is allowing rollback to an NRT-point. Today, you can only rollback to a commit point (segments_N). But an NRT reader also reflects a valid point in time view of the index (it just doesn't have a segments_N file, and its ref'd files are not fsync'd), so with this change you can close your old writer, open a new one from this NRT point, and revert all changes that had been done after the NRT reader was opened from the old writer. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows () - Build # 4895 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4895/ Java: No tests ran. Build Log: [...truncated 6 lines...] FATAL: null java.lang.NullPointerException at hudson.model.Slave.createLauncher(Slave.java:374) at hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:564) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:495) at hudson.model.Run.execute(Run.java:1744) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) ERROR: Publisher 'Archive the artifacts' failed: no workspace for Lucene-Solr-trunk-Windows #4895 ERROR: Publisher 'Publish JUnit test result report' failed: no workspace for Lucene-Solr-trunk-Windows #4895 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7631) Faceting on multivalued Trie fields with precisionStep != 0 can produce bogus value=0 in some situations
[
https://issues.apache.org/jira/browse/SOLR-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574939#comment-14574939
]
Hoss Man commented on SOLR-7631:
(long update due to jira being down last night, so i just kept a stream of
concious buffer which i'm now posting)
With the last patch, i ran this bash script...
{code}
# .. The current classpath supports the following names: [Asserting,
CheapBastard, FastCompressingStoredFields,
FastDecompressionCompressingStoredFields,
HighCompressionCompressingStoredFields, DummyCompressingStoredFields,
SimpleText, Lucene50]
codecs=(Asserting CheapBastard FastCompressingStoredFields
FastDecompressionCompressingStoredFields HighCompressionCompressingStoredFields
DummyCompressingStoredFields SimpleText Lucene50 random)
for c in ${codecs[@]}
do
echo $c
for i in {1..50}; do ant test -Dtestcase=TestTrieFacet -Dtests.verbose=true
-Dtests.codec=$c; done | tee $c.log.txt
done
{code}
the only codec with failures was random...
{noformat}
$ grep -c reproduce with *.log.txt
Asserting.log.txt:0
CheapBastard.log.txt:0
DummyCompressingStoredFields.log.txt:0
FastCompressingStoredFields.log.txt:0
FastDecompressionCompressingStoredFields.log.txt:0
HighCompressionCompressingStoredFields.log.txt:0
Lucene50.log.txt:0
random.log.txt:9
SimpleText.log.txt:0
{noformat}
Those 9 failures...
{noformat}
$ egrep reproduce with|test params *.log.txt | grep -A 1 reproduce with
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_enum
-Dtests.seed=FA4AA4357AB98B18 -Dtests.slow=true -Dtests.locale=ar_MA
-Dtests.timezone=America/Bogota -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_fc
-Dtests.seed=FA4AA4357AB98B18 -Dtests.slow=true -Dtests.locale=ar_MA
-Dtests.timezone=America/Bogota -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_fcs
-Dtests.seed=FA4AA4357AB98B18 -Dtests.slow=true -Dtests.locale=ar_MA
-Dtests.timezone=America/Bogota -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
random.log.txt: [junit4] 2 NOTE: test params are:
codec=Asserting(Lucene50): {foo_ti=PostingsFormat(name=MockRandom),
foo_i=Lucene50(blocksize=128), range_facet_l_dv=PostingsFormat(name=Asserting),
_version_=PostingsFormat(name=MockRandom),
multiDefault=Lucene50(blocksize=128),
intDefault=PostingsFormat(name=MockRandom), id=PostingsFormat(name=SimpleText),
range_facet_i_dv=PostingsFormat(name=MockRandom),
foo_ti1=PostingsFormat(name=Asserting), foo_i1=PostingsFormat(name=Asserting),
range_facet_l=PostingsFormat(name=MockRandom),
timestamp=PostingsFormat(name=MockRandom)},
docValues:{range_facet_l_dv=DocValuesFormat(name=Direct),
range_facet_i_dv=DocValuesFormat(name=Lucene50),
timestamp=DocValuesFormat(name=Lucene50)}, sim=DefaultSimilarity, locale=ar_MA,
timezone=America/Bogota
--
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_fcs
-Dtests.seed=7CE0E739965D7ECD -Dtests.slow=true -Dtests.locale=mt_MT
-Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_enum
-Dtests.seed=7CE0E739965D7ECD -Dtests.slow=true -Dtests.locale=mt_MT
-Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet -Dtests.method=testMultiValuedTrieP8_fc
-Dtests.seed=7CE0E739965D7ECD -Dtests.slow=true -Dtests.locale=mt_MT
-Dtests.timezone=Pacific/Bougainville -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
random.log.txt: [junit4] 2 NOTE: test params are:
codec=Asserting(Lucene50): {foo_ti=BlockTreeOrds(blocksize=128),
foo_i=PostingsFormat(name=LuceneFixedGap), range_facet_l_dv=FSTOrd50,
_version_=BlockTreeOrds(blocksize=128),
multiDefault=PostingsFormat(name=LuceneFixedGap),
intDefault=BlockTreeOrds(blocksize=128), id=FSTOrd50,
range_facet_i_dv=BlockTreeOrds(blocksize=128),
foo_ti1=PostingsFormat(name=Memory doPackFST= false), foo_i1=FSTOrd50,
range_facet_l=BlockTreeOrds(blocksize=128),
timestamp=BlockTreeOrds(blocksize=128)},
docValues:{range_facet_l_dv=DocValuesFormat(name=Memory),
range_facet_i_dv=DocValuesFormat(name=Asserting),
timestamp=DocValuesFormat(name=Asserting)},
sim=RandomSimilarityProvider(queryNorm=false,coord=yes): {}, locale=mt_MT,
timezone=Pacific/Bougainville
--
random.log.txt: [junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestTrieFacet
[jira] [Updated] (SOLR-7631) RandomCodec can cause Faceting on multivalued Trie fields with precisionStep != 0 can produce bogus value=0 in some test seeds
[
https://issues.apache.org/jira/browse/SOLR-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-7631:
---
Description:
Working through SOLR-7605, I've confirmed that the underlying problem exists
for regular {{field.facet}} situations, regardless of distrib mode, for Trie
fields that have a non-zero precisionStep. *this has only been reproduced when
the RandomCodec was in use*
The problem, when it manifests, is that faceting on a TrieIntField, using
{{facet.mincount=0}}, causes the facet results to include three instances of
facet the value 0 listed with a count of 0 -- even though no document in
the index contains this value at all...
{noformat}
[junit4] lst name=facet_fields
[junit4] lst name=foo_ti
[junit4] int name=2032/int
...
[junit4] int name=5021/int
[junit4] int name=00/int
[junit4] int name=00/int
[junit4] int name=00/int
{noformat}
This is concerning for a few reasons:
* In the case of PivotFaceting, getting duplicate values back from a single
shard like this triggers an assert in distributed queries and the request fails
-- even if asserts aren't enabled, the bogus 0 value can be propogated to
clients if they ask for facet.pivot.mincount=0
* Client code expecting a single (value,count) pair for each value may equally
be confused/broken by this response where the same value is returned multiple
times
* w/o knowing the root cause, It seems very possible that other nonsense values
may be getting returned -- ie: if the error only happens with fields utilizing
precisionStep, then it's likely related to the synthetic values used for faster
range queries, and other synthetic values may be getting included with bogus
counts
A Patch with a simple test that can demonstrate the bug fairly easily will be
attached shortly
was:
Working through SOLR-7605, I've confirmed that the underlying problem exists
for regular {{field.facet}} situations, regardless of distrib mode, for Trie
fields that have a non-zero precisionStep -- there's still ome other missing
piece of the puzzle i haven't figured out, but it relates in some way to some
of randomized factors we use in our tests (Codec? PostingFormat? ... no idea)
The problem, when it manifests, is that faceting on a TrieIntField, using
{{facet.mincount=0}}, causes the facet results to include three instances of
facet the value 0 listed with a count of 0 -- even though no document in
the index contains this value at all...
{noformat}
[junit4] lst name=facet_fields
[junit4] lst name=foo_ti
[junit4] int name=2032/int
...
[junit4] int name=5021/int
[junit4] int name=00/int
[junit4] int name=00/int
[junit4] int name=00/int
{noformat}
This is concerning for a few reasons:
* In the case of PivotFaceting, getting duplicate values back from a single
shard like this triggers an assert in distributed queries and the request fails
-- even if asserts aren't enabled, the bogus 0 value can be propogated to
clients if they ask for facet.pivot.mincount=0
* Client code expecting a single (value,count) pair for each value may equally
be confused/broken by this response where the same value is returned multiple
times
* w/o knowing the root cause, It seems very possible that other nonsense values
may be getting returned -- ie: if the error only happens with fields utilizing
precisionStep, then it's likely related to the synthetic values used for faster
range queries, and other synthetic values may be getting included with bogus
counts
A Patch with a simple test that can demonstrate the bug fairly easily will be
attached shortly
Summary: RandomCodec can cause Faceting on multivalued Trie fields with
precisionStep != 0 can produce bogus value=0 in some test seeds (was:
Faceting on multivalued Trie fields with precisionStep != 0 can produce bogus
value=0 in some situations)
re-reading my long comment from last night, i realized i kind of buried the
lead, which is: I was not able to reproduce this bug using any explicitly
specified -Dtests.codec other then random
RandomCodec can cause Faceting on multivalued Trie fields with precisionStep
!= 0 can produce bogus value=0 in some test seeds
Key: SOLR-7631
URL: https://issues.apache.org/jira/browse/SOLR-7631
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: SOLR-7631_test.patch, SOLR-7631_test.patch, log.tgz
Working through SOLR-7605, I've confirmed that the underlying problem exists
for regular {{field.facet}} situations, regardless of distrib mode, for Trie
fields that have a non-zero precisionStep.
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574916#comment-14574916
]
Shawn Heisey commented on SOLR-7642:
I think that if a chroot has been requested but it doesn't exist, it should be
created. We do the same thing if there's no cloud info in zookeeper at all,
don't we?
Should launching Solr in cloud mode using a ZooKeeper chroot create the
chroot znode if it doesn't exist?
-
Key: SOLR-7642
URL: https://issues.apache.org/jira/browse/SOLR-7642
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Priority: Minor
If you launch Solr for the first time in cloud mode using a ZooKeeper
connection string that includes a chroot leads to the following
initialization error:
{code}
ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
in ZkHost but the znode doesn't exist. localhost:2181/lan
at
org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
at
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
{code}
The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
to create the chroot znode (bootstrap action does this).
I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5805) QueryNodeImpl.removeFromParent does a lot of work without any effect
[
https://issues.apache.org/jira/browse/LUCENE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574999#comment-14574999
]
ASF subversion and git services commented on LUCENE-5805:
-
Commit 1683839 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1683839 ]
LUCENE-5805: QueryNodeImpl.removeFromParent was doing nothing, in a costly way
QueryNodeImpl.removeFromParent does a lot of work without any effect
Key: LUCENE-5805
URL: https://issues.apache.org/jira/browse/LUCENE-5805
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7.2, 4.9
Reporter: Christoph Kaser
Assignee: Michael McCandless
Attachments: LUCENE-5805.patch
The method _removeFromParent_ of _QueryNodeImpl_, calls _getChildren_ on the
parent and removes any occurrence of this from the result.
However, since a few releases, _getChildren_ returns a *copy* of the children
list, so the code has no effect (except creating a copy of the children list
which will then be thrown away).
Even worse, since _setChildren_ calls _removeFromParent_ on any previous
child, _setChildren_ now has a complexity of O(n^2) and creates a lot of
throw-away copies of the children list (for nodes with a lot of children)
{code}
public void removeFromParent() {
if (this.parent != null) {
ListQueryNode parentChildren = this.parent.getChildren();
IteratorQueryNode it = parentChildren.iterator();
while (it.hasNext()) {
if (it.next() == this) {
it.remove();
}
}
this.parent = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene / Solr 5.2 release notes
I’ve made drafts for the Lucene and Solr release notes - please feel free to edit or suggest edits: Lucene: https://wiki.apache.org/lucene-java/ReleaseNote52 Solr: http://wiki.apache.org/solr/ReleaseNote52 -- Anshum Gupta
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574897#comment-14574897
]
Timothy Potter commented on SOLR-7642:
--
This only affects 5.x and beyond since the 4.x line bootstrapped the
collection1 automatically.
Alternatively, if we don't want to support this, we should document the reason
in the ref guide.
Should launching Solr in cloud mode using a ZooKeeper chroot create the
chroot znode if it doesn't exist?
-
Key: SOLR-7642
URL: https://issues.apache.org/jira/browse/SOLR-7642
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Priority: Minor
If you launch Solr for the first time in cloud mode using a ZooKeeper
connection string that includes a chroot leads to the following
initialization error:
{code}
ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
in ZkHost but the znode doesn't exist. localhost:2181/lan
at
org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
at
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
{code}
The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
to create the chroot znode (bootstrap action does this).
I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
[
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574922#comment-14574922
]
Shawn Heisey commented on SOLR-7642:
If for some reason the create doesn't succeed, that's probably grounds for a
hard/fast failure that keeps Solr from starting.
Should launching Solr in cloud mode using a ZooKeeper chroot create the
chroot znode if it doesn't exist?
-
Key: SOLR-7642
URL: https://issues.apache.org/jira/browse/SOLR-7642
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Priority: Minor
If you launch Solr for the first time in cloud mode using a ZooKeeper
connection string that includes a chroot leads to the following
initialization error:
{code}
ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified
in ZkHost but the znode doesn't exist. localhost:2181/lan
at
org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
at
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
{code}
The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script
to create the chroot znode (bootstrap action does this).
I'm wondering if we shouldn't just create the znode if it doesn't exist? Or
is that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6527) TermWeight should not load norms when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6527: - Attachment: LUCENE-6527.patch Thanks Alan, that makes sense especially if we want to avoid exploding the number of parameters. I just updated the patch with your suggestion. TermWeight should not load norms when needsScores is false -- Key: LUCENE-6527 URL: https://issues.apache.org/jira/browse/LUCENE-6527 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6527.patch, LUCENE-6527.patch, LUCENE-6527.patch TermWeight currently loads norms all the time, even when needsScores is false. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-7613) solrcore.properties file should be loaded if it resides in ZooKeeper
This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties In my particular case the core won't load without some of the properties being specified. Is there a way to get those properties into ZK before you even create the new collection? It looks like you are adding properties to an already existing collection... -Steve On Fri, Jun 5, 2015 at 12:09 AM, Noble Paul noble.p...@gmail.com wrote: Replying here coz jira is down Let's get rid of solrcore.properties in cloud . We don't need it. It is not just reading that thing. We need to manage the lifecycle as well (editing, refreshing etc) This is the right way to do properties in solrcloud https://cwiki.apache.org/confluence/display/solr/Config+API#ConfigAPI-CommandsforUser-DefinedProperties On Fri, Jun 5, 2015 at 3:25 AM, Hoss Man (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/SOLR-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573660#comment-14573660 ] Hoss Man commented on SOLR-7613: Some relevant comments on this from the original mailing list discussion... Hoss.. bq. IIUC CoreDescriptor.loadExtraProperties is the relevent method ... it would need to build up the path including the core name and get the system level resource loader (CoreContainer.getResourceLoader()) to access it since the core doesn't exist yet so there is no core level ResourceLoader to use. Alan... bq. I think this is an oversight, rather than intentional (at least, I certainly didn't intend to write it like this!). The problem here will be that CoreDescriptors are currently built entirely from core.properties files, and the CoreLocators that construct them don't have any access to zookeeper. bq. Maybe the way forward is to move properties out of CoreDescriptor and have an entirely separate CoreProperties object that is built and returned by the ConfigSetService, and that is read via the ResourceLoader. This would fit in quite nicely with the changes I put up on SOLR-7570, in that you could have properties specified on the collection config overriding properties from the configset, and then local core-specific properties overriding both. Hoss... bq. But they do have access to the CoreContainer which is passed to the CoreDescriptor constructor -- it has all the ZK access you'd need at the time when loadExtraProperties() is called. Alan... bq. Yeah, you could do it like that. But looking at it further, I think solrcore.properties is actually being loaded in entirely the wrong place - it should be done by whatever is creating the CoreDescriptor, and then passed in as a Properties object to the CD constructor. At the moment, you can't refer to a property defined in solrcore.properties within your core.properties file. Hoss... bq. but if you look at it fro ma historical context, that doesn't really matter for the purpose that solrcore.properties was intended for -- it predates core discover, and was only intended as a way to specify user level properties that could then be substituted in the solrconfig.xml or dih.xml or schema.xml bq. ie: making it possible to use a solrcore.prop value to set a core.prop value might be a nice to have, but it's definitely not what it was intended for, so it shouldn't really be a blocker to getting the same (original) basic functionality working in SolrCloud. Honestly, even ignoring the historical context, it seems like a chicken and egg problem to me -- should it be possible to use a solrecore.properties variable to set the value of another variable in core.properties? or should it be possible to use a core.properties variable to set the value of another variable in solrcore.properties? the simplest thing for people to udnerstand would probably be to just say that they are independent, loaded seperately, and cause an error if you try to define the same value in both (i doubt that's currently enforced, but it probably should be) solrcore.properties file should be loaded if it resides in ZooKeeper Key: SOLR-7613 URL: https://issues.apache.org/jira/browse/SOLR-7613 Project: Solr Issue Type: Bug Reporter: Steve Davids Fix For: 5.3 The solrcore.properties file is used to load user defined properties for use primarily in the solrconfig.xml file, though this properties file will only load if it is resident in the core/conf directory on the physical disk, it will not load if it is in ZK's core/conf directory. There should be a mechanism to allow a core properties file to be specified in ZK and can be updated appropriately along with being able to
[jira] [Created] (SOLR-7641) bin/solr script checks for the presence of the JAR command before resolving java (where it might also find jar)
Timothy Potter created SOLR-7641:
Summary: bin/solr script checks for the presence of the JAR
command before resolving java (where it might also find jar)
Key: SOLR-7641
URL: https://issues.apache.org/jira/browse/SOLR-7641
Project: Solr
Issue Type: Bug
Affects Versions: 5.1, 5.0, 5.2
Reporter: Timothy Potter
Fix For: 5.3
I have SOLR_JAVA_HOME set to point to a valid JDK in my bin/solr.in.sh
{code}
SOLR_JAVA_HOME=/home/ubuntu/jdk1.8.0_45
{code}
Note: I do not have JAVA_HOME set in my environment nor is it in my PATH.
And yet, when I run bin/solr, I get the following error:
{code}
$ bin/solr start -cloud -p 8984 -d cloud84 -f
This script requires extracting a WAR file with either the jar or unzip
utility, please install these utilities or contact your administrator for
assistance.
{code}
I think this code in bin/solr should be after the script resolves the location
of java so it can check there for jar and use that rather than failing the
script as it's doing now.
{code}
if hash jar 2/dev/null ; then # hash returns true if jar is on the path
UNPACK_WAR_CMD=($(command -v jar) xf)
elif hash unzip 2/dev/null ; then # hash returns true if unzip is on the path
UNPACK_WAR_CMD=($(command -v unzip) -q)
else
echo -e This script requires extracting a WAR file with either the jar or
unzip utility, please install these utilities or contact your administrator for
assistance.
exit 1
fi
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574785#comment-14574785
]
Shawn Heisey commented on SOLR-7640:
The URL is parsed by the servlet container, which doesn't have any visibility
into Solr and cannot know the solr home.
Even if that info makes past the servlet container into Solr, it is unlikely
that the admin handler is set up to parse property substitution. I've never
seen this capability.
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result {code}${solr.solr.home}{code} is replaced with empty value (or
wit default if we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder
and separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this
works on windows, but unix systems do not allow relative path with non
existent folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
{code}${solr.solr.home}{code}, but it i's empty (but it works in config files)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-7640:
---
Issue Type: Wish (was: Bug)
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Wish
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result {code}${solr.solr.home}{code} is replaced with empty value (or
wit default if we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder
and separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this
works on windows, but unix systems do not allow relative path with non
existent folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
{code}${solr.solr.home}{code}, but it i's empty (but it works in config files)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?
Timothy Potter created SOLR-7642:
Summary: Should launching Solr in cloud mode using a ZooKeeper
chroot create the chroot znode if it doesn't exist?
Key: SOLR-7642
URL: https://issues.apache.org/jira/browse/SOLR-7642
Project: Solr
Issue Type: Improvement
Reporter: Timothy Potter
Priority: Minor
If you launch Solr for the first time in cloud mode using a ZooKeeper
connection string that includes a chroot leads to the following initialization
error:
{code}
ERROR - 2015-06-05 17:15:50.410; [ ] org.apache.solr.common.SolrException;
null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified in
ZkHost but the znode doesn't exist. localhost:2181/lan
at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
at
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
{code}
The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script to
create the chroot znode (bootstrap action does this).
I'm wondering if we shouldn't just create the znode if it doesn't exist? Or is
that some violation of using a chroot?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574788#comment-14574788
]
Shawn Heisey commented on SOLR-7640:
This is an example of something we *MIGHT* be able to support if we turn Solr
into a standalone application instead of a webapp.
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Wish
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result {code}${solr.solr.home}{code} is replaced with empty value (or
wit default if we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder
and separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this
works on windows, but unix systems do not allow relative path with non
existent folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
{code}${solr.solr.home}{code}, but it i's empty (but it works in config files)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5954) Store lucene version in segment_N
[
https://issues.apache.org/jira/browse/LUCENE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574730#comment-14574730
]
Michael McCandless commented on LUCENE-5954:
Oh, on Rob's feedback: I'll change that confusing {{// else leave null}}
comment to {{// else compute the min version down below in the for loop}}.
Store lucene version in segment_N
-
Key: LUCENE-5954
URL: https://issues.apache.org/jira/browse/LUCENE-5954
Project: Lucene - Core
Issue Type: Bug
Reporter: Ryan Ernst
Assignee: Michael McCandless
Fix For: Trunk, 5.3
Attachments: LUCENE-5954.patch, LUCENE-5954.patch
It would be nice to have the version of lucene that wrote segments_N, so that
we can use this to determine which major version an index was written with
(for upgrading across major versions). I think this could be squeezed in
just after the segments_N header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5805) QueryNodeImpl.removeFromParent does a lot of work without any effect
[
https://issues.apache.org/jira/browse/LUCENE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-5805:
--
Assignee: Michael McCandless
QueryNodeImpl.removeFromParent does a lot of work without any effect
Key: LUCENE-5805
URL: https://issues.apache.org/jira/browse/LUCENE-5805
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7.2, 4.9
Reporter: Christoph Kaser
Assignee: Michael McCandless
Attachments: LUCENE-5805.patch
The method _removeFromParent_ of _QueryNodeImpl_, calls _getChildren_ on the
parent and removes any occurrence of this from the result.
However, since a few releases, _getChildren_ returns a *copy* of the children
list, so the code has no effect (except creating a copy of the children list
which will then be thrown away).
Even worse, since _setChildren_ calls _removeFromParent_ on any previous
child, _setChildren_ now has a complexity of O(n^2) and creates a lot of
throw-away copies of the children list (for nodes with a lot of children)
{code}
public void removeFromParent() {
if (this.parent != null) {
ListQueryNode parentChildren = this.parent.getChildren();
IteratorQueryNode it = parentChildren.iterator();
while (it.hasNext()) {
if (it.next() == this) {
it.remove();
}
}
this.parent = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5805) QueryNodeImpl.removeFromParent does a lot of work without any effect
[
https://issues.apache.org/jira/browse/LUCENE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574778#comment-14574778
]
Michael McCandless commented on LUCENE-5805:
Oh this is quite bad, thanks [~caomanhdat]
QueryNodeImpl.removeFromParent does a lot of work without any effect
Key: LUCENE-5805
URL: https://issues.apache.org/jira/browse/LUCENE-5805
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7.2, 4.9
Reporter: Christoph Kaser
Attachments: LUCENE-5805.patch
The method _removeFromParent_ of _QueryNodeImpl_, calls _getChildren_ on the
parent and removes any occurrence of this from the result.
However, since a few releases, _getChildren_ returns a *copy* of the children
list, so the code has no effect (except creating a copy of the children list
which will then be thrown away).
Even worse, since _setChildren_ calls _removeFromParent_ on any previous
child, _setChildren_ now has a complexity of O(n^2) and creates a lot of
throw-away copies of the children list (for nodes with a lot of children)
{code}
public void removeFromParent() {
if (this.parent != null) {
ListQueryNode parentChildren = this.parent.getChildren();
IteratorQueryNode it = parentChildren.iterator();
while (it.hasNext()) {
if (it.next() == this) {
it.remove();
}
}
this.parent = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-6528) Sort by SortField.FIELD_SCORE produces NaN scores
[
https://issues.apache.org/jira/browse/LUCENE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ahmet Arslan closed LUCENE-6528.
Resolution: Not A Problem
Ups thanks for the info and sorry for the noise. When I used
{{searcher.search(query, 10, sort, true, false)}} test passes.
Sort by SortField.FIELD_SCORE produces NaN scores
-
Key: LUCENE-6528
URL: https://issues.apache.org/jira/browse/LUCENE-6528
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.1
Reporter: Ahmet Arslan
Labels: sort
Attachments: LUCENE-6528.patch, LUCENE-6528.patch
Explicit sort by document score/relevance (SortField.FIELD_SCORE) yields Not
a Number (NaN) scores.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
[
https://issues.apache.org/jira/browse/SOLR-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton updated SOLR-7640:
Description:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${solr.solr.home} is replaced with empty value (or wit default if
we specify it)
{quote}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{quote}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
was:
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${solr.solr.home} is replaced with empty value (or wit default if
we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
-
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
[jira] [Created] (SOLR-7640) ${solr.solr.home} passed via url is empty when creating a core (admin CREATE)
Anton created SOLR-7640:
---
Summary: ${solr.solr.home} passed via url is empty when creating a
core (admin CREATE)
Key: SOLR-7640
URL: https://issues.apache.org/jira/browse/SOLR-7640
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Anton
Here is example of the command we use:
{code}
http://192.168.0.47:8983/solr/admin/cores?action=CREATEname=tickets_coreinstanceDir=cores/ticketsconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlschema=${solr.solr.home}/schemas/tickets/conf/schema.xmldataDir=../../indexes/tickets/persist=truetransient=trueloadOnStartup=false
{code}
As a result ${solr.solr.home} is replaced with empty value (or wit default if
we specify it)
{code}
4344140 [qtp853251756-15] INFO org.apache.solr.servlet.SolrDispatchFilter [
] Ц
[admin] webapp=null path=/admin/cores
params={schema=${solr.solr.home}/schemas/tickets/conf/schema.xmlloadOnStartup=falseinstanceDir=cores/ticketstransient=truename=tickets_coreaction=CREATEconfig=${solr.solr.home}/schemas/tickets/conf/solrconfig.xmlpersist=truedataDir=../../indexes/tickets/}
status=400 QTime=57
4344347 [qtp853251756-12] ERROR org.apache.solr.servlet.SolrDispatchFilter [
] Ц
null:org.apache.solr.common.SolrException: SolrCore 'tickets_core' is not
available due to init failure:
Could not load conf for core tickets_core: Error loading solr config from
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
{code}
d:\development\projects\helprace\main\solr\cores\tickets\conf\/schemas/tickets/conf/solrconfig.xml
In case of questions why we do in this way:
We have parrallel tests running. On each separate process we create a single
solr core with same schema.
Due to this we use same schema and solrconfig files, separate index folder and
separate instanceDir (core.properites for each core).
Copying config files is not possible because core has random name and is
created dynamically.
When the core is being created it's instanceDir does not exist yet and due to
this we cannot use relative path from this folder to config files. (this works
on windows, but unix systems do not allow relative path with non existent
folder)
We tried to use absolute path for schema.xml and solrconfig.xml and used
${solr.solr.home}, but it i's empty (but it works in config files)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6526) Make AssertingWeight check that scores are not computed when needsScores is false
[ https://issues.apache.org/jira/browse/LUCENE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574354#comment-14574354 ] Robert Muir commented on LUCENE-6526: - +1 Make AssertingWeight check that scores are not computed when needsScores is false - Key: LUCENE-6526 URL: https://issues.apache.org/jira/browse/LUCENE-6526 Project: Lucene - Core Issue Type: Test Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-6526.patch Today nothing prevents you from calling score() if you don't need scores. But we could make AssertingWeight check it in order to make sure that we do not waste resources computing something we don't need. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3192 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3192/ No tests ran. Build Log: [...truncated 192 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:536: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:484: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:61: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/extra-targets.xml:39: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build.xml:50: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:1436: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:991: Could not read or create hints file: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/.caches/test-stats/core/timehints.txt Total time: 18 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Lucene-Solr-Tests-5.x-Java7 #3186 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 464 bytes Compression is 0.0% Took 0.1 sec Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3719) Add instant search capability to example/files /browse
[ https://issues.apache.org/jira/browse/SOLR-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-3719. Resolution: Fixed Committed: oops, forgot to put JIRA tag on commit message. trunk is r1683778, branch_5x is 1683779. I adjusted a couple of things from Esther's patch: streamlined some macros (required some moving around in the built-in VrW ones), added mincount=0 to the doc_type facet so that the type doesn't disappear on the UI in instant search, and added start (effectively page number) when switching locales so it doesn't jump back to page 1. Add instant search capability to example/files /browse Key: SOLR-3719 URL: https://issues.apache.org/jira/browse/SOLR-3719 Project: Solr Issue Type: New Feature Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: Trunk, 5.3 Attachments: SOLR-3719.patch, SOLR-3719.patch, SOLR-3719.patch Once upon a time I tinkered with this in a personal github fork https://github.com/erikhatcher/lucene-solr/commits/instant_search/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6528) Sort by SortField.FIELD_SCORE produces NaN scores
[ https://issues.apache.org/jira/browse/LUCENE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14574681#comment-14574681 ] Adrien Grand commented on LUCENE-6528: -- Unfortunately that's expected: you need to pass doDocScores=true if you want to have scores filled in your ScoreDoc instances. Otherwise Lucene just uses FieldDoc instances instead of ScoreDoc instances with a NaN score and where one of the sort fields is the score. However I agree this is confusing, we should try to fix these APIs to not expose the score if it was not computed. Sort by SortField.FIELD_SCORE produces NaN scores - Key: LUCENE-6528 URL: https://issues.apache.org/jira/browse/LUCENE-6528 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 5.1 Reporter: Ahmet Arslan Labels: sort Attachments: LUCENE-6528.patch, LUCENE-6528.patch Explicit sort by document score/relevance (SortField.FIELD_SCORE) yields Not a Number (NaN) scores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7628) Investigate not using apacheds-all jar
[ https://issues.apache.org/jira/browse/SOLR-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7628: - Attachment: SOLR-7628.patch Here's a patch. Some notes: - There are quite a number of dependencies I had to add, but it seems worth it to not have conflicting jars on the classpath - I didn't add every dependency that shows up in mvn dependency:tree, just the dependencies that needed to be added to get the tests to pass. Given that we only use the MiniKDC for tests, we should find any places where this could be in an issue automatically in the future. This seems like a reasonable approach over maintaining more dependencies. - I normalized the version of bouncycastle/bcprov we are using -- that didn't seem to cause any issues - I could not normalization the version of the antlr dependency. MiniKDC uses antlr2, which doesn't seem compatible with antlr3. Investigate not using apacheds-all jar -- Key: SOLR-7628 URL: https://issues.apache.org/jira/browse/SOLR-7628 Project: Solr Issue Type: Bug Components: SolrCloud, Tests Affects Versions: 5.1, 6 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7628.patch Over in SOLR-6915 it was reported that using the apacheds-all jar can be an issue because it has some conflicting classes: bq. This apacheds-all jar seems troublesome - currently it has conflicting slf4j classes in it... See: https://issues.apache.org/jira/browse/SOLR-6915?focusedCommentId=14569870page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14569870 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6482) Class loading deadlock relating to NamedSPILoader
[
https://issues.apache.org/jira/browse/LUCENE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shikhar Bhushan updated LUCENE-6482:
Attachment: CodecLoadingDeadlockTest.java
Class loading deadlock relating to NamedSPILoader
-
Key: LUCENE-6482
URL: https://issues.apache.org/jira/browse/LUCENE-6482
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.9.1
Reporter: Shikhar Bhushan
Assignee: Uwe Schindler
Attachments: CodecLoadingDeadlockTest.java
This issue came up for us several times with Elasticsearch 1.3.4 (Lucene
4.9.1), with many threads seeming deadlocked but RUNNABLE:
{noformat}
elasticsearch[search77-es2][generic][T#43] #160 daemon prio=5 os_prio=0
tid=0x7f79180c5800 nid=0x3d1f in Object.wait() [0x7f79d9289000]
java.lang.Thread.State: RUNNABLE
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:457)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:912)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:758)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:453)
at
org.elasticsearch.common.lucene.Lucene.readSegmentInfos(Lucene.java:98)
at org.elasticsearch.index.store.Store.readSegmentsInfo(Store.java:126)
at org.elasticsearch.index.store.Store.access$300(Store.java:76)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.buildMetadata(Store.java:465)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.init(Store.java:456)
at
org.elasticsearch.index.store.Store.readMetadataSnapshot(Store.java:281)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.listStoreMetaData(TransportNodesListShardStoreMetaData.java:186)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:140)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:61)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:277)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:268)
at
org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
It didn't really make sense to see RUNNABLE threads in Object.wait(), but
this seems to be symptomatic of deadlocks in static initialization
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I found LUCENE-5573 as an instance of this having come up with Lucene code
before.
I'm not sure what exactly is going on, but the deadlock in this case seems to
involve these threads:
{noformat}
elasticsearch[search77-es2][clusterService#updateTask][T#1] #79 daemon
prio=5 os_prio=0 tid=0x7f7b155ff800 nid=0xd49 in Object.wait()
[0x7f79daed8000]
java.lang.Thread.State: RUNNABLE
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:433)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
- locked 0x00061fef4968 (a org.apache.lucene.util.NamedSPILoader)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:37)
at
org.apache.lucene.codecs.PostingsFormat.clinit(PostingsFormat.java:44)
at
org.elasticsearch.index.codec.postingsformat.PostingFormats.clinit(PostingFormats.java:67)
at
org.elasticsearch.index.codec.CodecModule.configurePostingsFormats(CodecModule.java:126)
at
org.elasticsearch.index.codec.CodecModule.configure(CodecModule.java:178)
at
org.elasticsearch.common.inject.AbstractModule.configure(AbstractModule.java:60)
- locked 0x00061fef49e8 (a
org.elasticsearch.index.codec.CodecModule)
at
[jira] [Updated] (LUCENE-6482) Class loading deadlock relating to NamedSPILoader
[
https://issues.apache.org/jira/browse/LUCENE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shikhar Bhushan updated LUCENE-6482:
Attachment: (was: CodecLoadingDeadlockTest.java)
Class loading deadlock relating to NamedSPILoader
-
Key: LUCENE-6482
URL: https://issues.apache.org/jira/browse/LUCENE-6482
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.9.1
Reporter: Shikhar Bhushan
Assignee: Uwe Schindler
Attachments: CodecLoadingDeadlockTest.java
This issue came up for us several times with Elasticsearch 1.3.4 (Lucene
4.9.1), with many threads seeming deadlocked but RUNNABLE:
{noformat}
elasticsearch[search77-es2][generic][T#43] #160 daemon prio=5 os_prio=0
tid=0x7f79180c5800 nid=0x3d1f in Object.wait() [0x7f79d9289000]
java.lang.Thread.State: RUNNABLE
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:457)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:912)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:758)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:453)
at
org.elasticsearch.common.lucene.Lucene.readSegmentInfos(Lucene.java:98)
at org.elasticsearch.index.store.Store.readSegmentsInfo(Store.java:126)
at org.elasticsearch.index.store.Store.access$300(Store.java:76)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.buildMetadata(Store.java:465)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.init(Store.java:456)
at
org.elasticsearch.index.store.Store.readMetadataSnapshot(Store.java:281)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.listStoreMetaData(TransportNodesListShardStoreMetaData.java:186)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:140)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:61)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:277)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:268)
at
org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
It didn't really make sense to see RUNNABLE threads in Object.wait(), but
this seems to be symptomatic of deadlocks in static initialization
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I found LUCENE-5573 as an instance of this having come up with Lucene code
before.
I'm not sure what exactly is going on, but the deadlock in this case seems to
involve these threads:
{noformat}
elasticsearch[search77-es2][clusterService#updateTask][T#1] #79 daemon
prio=5 os_prio=0 tid=0x7f7b155ff800 nid=0xd49 in Object.wait()
[0x7f79daed8000]
java.lang.Thread.State: RUNNABLE
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:433)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
- locked 0x00061fef4968 (a org.apache.lucene.util.NamedSPILoader)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:37)
at
org.apache.lucene.codecs.PostingsFormat.clinit(PostingsFormat.java:44)
at
org.elasticsearch.index.codec.postingsformat.PostingFormats.clinit(PostingFormats.java:67)
at
org.elasticsearch.index.codec.CodecModule.configurePostingsFormats(CodecModule.java:126)
at
org.elasticsearch.index.codec.CodecModule.configure(CodecModule.java:178)
at
org.elasticsearch.common.inject.AbstractModule.configure(AbstractModule.java:60)
- locked 0x00061fef49e8 (a
org.elasticsearch.index.codec.CodecModule)
at
[jira] [Commented] (LUCENE-6482) Class loading deadlock relating to NamedSPILoader
[
https://issues.apache.org/jira/browse/LUCENE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575221#comment-14575221
]
Uwe Schindler commented on LUCENE-6482:
---
Many thanks. Maybe my test was too complicated (I used IndexReaders to
reproduce your usecase). This is much easier. I think it might be even easier
to reproduce if you use a CyclicBarrier for starting both threads at the exact
same time.
Once I reproduced I will check into fixing this. I already had the idea to
synchronize the ServiceLoader component by Lucene against a single static lock
instance. But it is good to have a reproduce case. So I can better check that a
fix is effective.
Class loading deadlock relating to NamedSPILoader
-
Key: LUCENE-6482
URL: https://issues.apache.org/jira/browse/LUCENE-6482
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.9.1
Reporter: Shikhar Bhushan
Assignee: Uwe Schindler
Attachments: CodecLoadingDeadlockTest.java
This issue came up for us several times with Elasticsearch 1.3.4 (Lucene
4.9.1), with many threads seeming deadlocked but RUNNABLE:
{noformat}
elasticsearch[search77-es2][generic][T#43] #160 daemon prio=5 os_prio=0
tid=0x7f79180c5800 nid=0x3d1f in Object.wait() [0x7f79d9289000]
java.lang.Thread.State: RUNNABLE
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:457)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:912)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:758)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:453)
at
org.elasticsearch.common.lucene.Lucene.readSegmentInfos(Lucene.java:98)
at org.elasticsearch.index.store.Store.readSegmentsInfo(Store.java:126)
at org.elasticsearch.index.store.Store.access$300(Store.java:76)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.buildMetadata(Store.java:465)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.init(Store.java:456)
at
org.elasticsearch.index.store.Store.readMetadataSnapshot(Store.java:281)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.listStoreMetaData(TransportNodesListShardStoreMetaData.java:186)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:140)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:61)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:277)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:268)
at
org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
It didn't really make sense to see RUNNABLE threads in Object.wait(), but
this seems to be symptomatic of deadlocks in static initialization
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I found LUCENE-5573 as an instance of this having come up with Lucene code
before.
I'm not sure what exactly is going on, but the deadlock in this case seems to
involve these threads:
{noformat}
elasticsearch[search77-es2][clusterService#updateTask][T#1] #79 daemon
prio=5 os_prio=0 tid=0x7f7b155ff800 nid=0xd49 in Object.wait()
[0x7f79daed8000]
java.lang.Thread.State: RUNNABLE
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:433)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
- locked 0x00061fef4968 (a org.apache.lucene.util.NamedSPILoader)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:37)
at
org.apache.lucene.codecs.PostingsFormat.clinit(PostingsFormat.java:44)
at
[jira] [Resolved] (LUCENE-5805) QueryNodeImpl.removeFromParent does a lot of work without any effect
[
https://issues.apache.org/jira/browse/LUCENE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-5805.
Resolution: Fixed
Fix Version/s: 5.3
Trunk
Thanks Christoph and [~caomanhdat]!
QueryNodeImpl.removeFromParent does a lot of work without any effect
Key: LUCENE-5805
URL: https://issues.apache.org/jira/browse/LUCENE-5805
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7.2, 4.9
Reporter: Christoph Kaser
Assignee: Michael McCandless
Fix For: Trunk, 5.3
Attachments: LUCENE-5805.patch
The method _removeFromParent_ of _QueryNodeImpl_, calls _getChildren_ on the
parent and removes any occurrence of this from the result.
However, since a few releases, _getChildren_ returns a *copy* of the children
list, so the code has no effect (except creating a copy of the children list
which will then be thrown away).
Even worse, since _setChildren_ calls _removeFromParent_ on any previous
child, _setChildren_ now has a complexity of O(n^2) and creates a lot of
throw-away copies of the children list (for nodes with a lot of children)
{code}
public void removeFromParent() {
if (this.parent != null) {
ListQueryNode parentChildren = this.parent.getChildren();
IteratorQueryNode it = parentChildren.iterator();
while (it.hasNext()) {
if (it.next() == this) {
it.remove();
}
}
this.parent = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6522) Reproducible fieldcache AIOOBE only on J9
[
https://issues.apache.org/jira/browse/LUCENE-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575200#comment-14575200
]
Kevin Langman commented on LUCENE-6522:
---
Can you give me the java -version output from the JVM used when you hit the
problem?
Reproducible fieldcache AIOOBE only on J9
-
Key: LUCENE-6522
URL: https://issues.apache.org/jira/browse/LUCENE-6522
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Haven't dug in yet, just:
* reproduces easily on J9
* does not happen on Oracle JVM
{noformat}
[junit4] Suite: org.apache.lucene.uninverting.TestFieldCacheVsDocValues
[junit4] IGNOR/A 0.51s J2 |
TestFieldCacheVsDocValues.testHugeBinaryValueLimit
[junit4] Assumption #1: test requires codec with limits on max binary
field length
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestFieldCacheVsDocValues
-Dtests.method=testSortedSetFixedLengthVsUninvertedField
-Dtests.seed=831619B333C362E6 -Dtests.locale=es_UY
-Dtests.timezone=Atlantic/Bermuda -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.54s J2 |
TestFieldCacheVsDocValues.testSortedSetFixedLengthVsUninvertedField
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException
[junit4] at
__randomizedtesting.SeedInfo.seed([831619B333C362E6:B6EC641493EA4AD3]:0)
[junit4] at
org.apache.lucene.uninverting.DocTermOrds$OrdWrappedTermsEnum.seekCeil(DocTermOrds.java:692)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:570)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:511)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.doTestSortedSetVsUninvertedField(TestFieldCacheVsDocValues.java:385)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.testSortedSetFixedLengthVsUninvertedField(TestFieldCacheVsDocValues.java:105)
[junit4] at java.lang.Thread.run(Thread.java:785)
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestFieldCacheVsDocValues
-Dtests.method=testSortedSetVariableLengthVsUninvertedField
-Dtests.seed=831619B333C362E6 -Dtests.locale=es_UY
-Dtests.timezone=Atlantic/Bermuda -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.42s J2 |
TestFieldCacheVsDocValues.testSortedSetVariableLengthVsUninvertedField
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException
[junit4] at
__randomizedtesting.SeedInfo.seed([831619B333C362E6:2AB51ED6D324E426]:0)
[junit4] at
org.apache.lucene.uninverting.DocTermOrds$OrdWrappedTermsEnum.seekCeil(DocTermOrds.java:692)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:570)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:511)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.doTestSortedSetVsUninvertedField(TestFieldCacheVsDocValues.java:385)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.testSortedSetVariableLengthVsUninvertedField(TestFieldCacheVsDocValues.java:112)
[junit4] at java.lang.Thread.run(Thread.java:785)
[junit4] 2 NOTE: leaving temporary files on disk at:
/home/rmuir/workspace/trunk-ibm/lucene/build/misc/test/J2/temp/lucene.uninverting.TestFieldCacheVsDocValues
831619B333C362E6-001
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene50):
{indexed=FSTOrd50, id=Lucene50(blocksize=128)},
docValues:{dv=DocValuesFormat(name=Asserting),
field=DocValuesFormat(name=Asserting)}, sim=DefaultSimilarity, locale=es_UY,
timezone=Atlantic/Bermuda
[junit4] 2 NOTE: Linux 3.13.0-49-generic amd64/IBM Corporation 1.8.0
(64-bit)/cpus=8,threads=1,free=10179616,total=32243712
[junit4] 2 NOTE: All tests run in this JVM: [TestDocTermOrds,
TestNumericTerms32, TestFieldCacheVsDocValues]
[junit4] Completed [21/25] on J2 in 4.50s, 10 tests, 2 errors, 1 skipped
FAILURES!
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7643) Function queries don't support hash # in field name
DAG Support created SOLR-7643: - Summary: Function queries don't support hash # in field name Key: SOLR-7643 URL: https://issues.apache.org/jira/browse/SOLR-7643 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 4.7.2 Reporter: DAG Support Priority: Minor I have some index documents with both table_name and #table_name fields. If I use a function query with table_name: SolrQuery query = new SolrQuery(); query.add(fl , exists(table_name)); it works, returning results like this: docbool name=exists(table_name)true/bool/doc However, if I use #table_name: query.add(fl , exists(#table_name)); it returns empty documents like this: doc/doc -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7628) Investigate not using apacheds-all jar
[ https://issues.apache.org/jira/browse/SOLR-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575065#comment-14575065 ] Gregory Chanan commented on SOLR-7628: -- Looks like hadoop hit this issue as well - https://issues.apache.org/jira/browse/HADOOP-10100 Investigate not using apacheds-all jar -- Key: SOLR-7628 URL: https://issues.apache.org/jira/browse/SOLR-7628 Project: Solr Issue Type: Bug Components: SolrCloud, Tests Affects Versions: 5.1, 6 Reporter: Gregory Chanan Assignee: Gregory Chanan Over in SOLR-6915 it was reported that using the apacheds-all jar can be an issue because it has some conflicting classes: bq. This apacheds-all jar seems troublesome - currently it has conflicting slf4j classes in it... See: https://issues.apache.org/jira/browse/SOLR-6915?focusedCommentId=14569870page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14569870 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6482) Class loading deadlock relating to NamedSPILoader
[
https://issues.apache.org/jira/browse/LUCENE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shikhar Bhushan updated LUCENE-6482:
Attachment: CodecLoadingDeadlockTest.java
[~thetaphi] I have had some luck reproducing the problem quite consistently
with the attached test. If you uncomment the first line in the main() so that
Codec is previously initialized before the threads start, the deadlock doesn't
happen.
Class loading deadlock relating to NamedSPILoader
-
Key: LUCENE-6482
URL: https://issues.apache.org/jira/browse/LUCENE-6482
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.9.1
Reporter: Shikhar Bhushan
Assignee: Uwe Schindler
Attachments: CodecLoadingDeadlockTest.java
This issue came up for us several times with Elasticsearch 1.3.4 (Lucene
4.9.1), with many threads seeming deadlocked but RUNNABLE:
{noformat}
elasticsearch[search77-es2][generic][T#43] #160 daemon prio=5 os_prio=0
tid=0x7f79180c5800 nid=0x3d1f in Object.wait() [0x7f79d9289000]
java.lang.Thread.State: RUNNABLE
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:457)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:912)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:758)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:453)
at
org.elasticsearch.common.lucene.Lucene.readSegmentInfos(Lucene.java:98)
at org.elasticsearch.index.store.Store.readSegmentsInfo(Store.java:126)
at org.elasticsearch.index.store.Store.access$300(Store.java:76)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.buildMetadata(Store.java:465)
at
org.elasticsearch.index.store.Store$MetadataSnapshot.init(Store.java:456)
at
org.elasticsearch.index.store.Store.readMetadataSnapshot(Store.java:281)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.listStoreMetaData(TransportNodesListShardStoreMetaData.java:186)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:140)
at
org.elasticsearch.indices.store.TransportNodesListShardStoreMetaData.nodeOperation(TransportNodesListShardStoreMetaData.java:61)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:277)
at
org.elasticsearch.action.support.nodes.TransportNodesOperationAction$NodeTransportHandler.messageReceived(TransportNodesOperationAction.java:268)
at
org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
It didn't really make sense to see RUNNABLE threads in Object.wait(), but
this seems to be symptomatic of deadlocks in static initialization
(http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html).
I found LUCENE-5573 as an instance of this having come up with Lucene code
before.
I'm not sure what exactly is going on, but the deadlock in this case seems to
involve these threads:
{noformat}
elasticsearch[search77-es2][clusterService#updateTask][T#1] #79 daemon
prio=5 os_prio=0 tid=0x7f7b155ff800 nid=0xd49 in Object.wait()
[0x7f79daed8000]
java.lang.Thread.State: RUNNABLE
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:433)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
- locked 0x00061fef4968 (a org.apache.lucene.util.NamedSPILoader)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.init(NamedSPILoader.java:37)
at
org.apache.lucene.codecs.PostingsFormat.clinit(PostingsFormat.java:44)
at
org.elasticsearch.index.codec.postingsformat.PostingFormats.clinit(PostingFormats.java:67)
at
org.elasticsearch.index.codec.CodecModule.configurePostingsFormats(CodecModule.java:126)
at
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b12) - Build # 12952 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12952/ Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseG1GC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.search.TestStressRecovery Error Message: 10 threads leaked from SUITE scope at org.apache.solr.search.TestStressRecovery: 1) Thread[id=8234, name=WRITER3, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 2) Thread[id=8233, name=WRITER2, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 3) Thread[id=8239, name=WRITER8, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 4) Thread[id=8232, name=WRITER1, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 5) Thread[id=8231, name=WRITER0, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 6) Thread[id=8235, name=WRITER4, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) at org.apache.solr.search.TestStressRecovery$1.run(TestStressRecovery.java:112) 7) Thread[id=8238, name=WRITER7, state=WAITING, group=TGRP-TestStressRecovery] at sun.misc.Unsafe.park(Native
[jira] [Updated] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-7458: Attachment: Data Locality.png So... It turns out that my problem where I thought it was not updating was completely unrelated. Attached is a screenshot for a 4.10.3 based patch showing what it looks like there. Will be the same in trunk, naturally, this is the one I happened to have available. I've got a new patch that also adds some testing, so I think we are getting close to wrapped up here. Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 12776 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12776/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls Error Message: Shard split did not complete. Last recorded state: running expected:[completed] but was:[running] Stack Trace: org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: running expected:[completed] but was:[running] at __randomizedtesting.SeedInfo.seed([5F2A4D471737526A:74EC126115DFABE]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-5805) QueryNodeImpl.removeFromParent does a lot of work without any effect
[
https://issues.apache.org/jira/browse/LUCENE-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575073#comment-14575073
]
ASF subversion and git services commented on LUCENE-5805:
-
Commit 1683853 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1683853 ]
LUCENE-5805: QueryNodeImpl.removeFromParent was doing nothing, in a costly way
QueryNodeImpl.removeFromParent does a lot of work without any effect
Key: LUCENE-5805
URL: https://issues.apache.org/jira/browse/LUCENE-5805
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 4.7.2, 4.9
Reporter: Christoph Kaser
Assignee: Michael McCandless
Attachments: LUCENE-5805.patch
The method _removeFromParent_ of _QueryNodeImpl_, calls _getChildren_ on the
parent and removes any occurrence of this from the result.
However, since a few releases, _getChildren_ returns a *copy* of the children
list, so the code has no effect (except creating a copy of the children list
which will then be thrown away).
Even worse, since _setChildren_ calls _removeFromParent_ on any previous
child, _setChildren_ now has a complexity of O(n^2) and creates a lot of
throw-away copies of the children list (for nodes with a lot of children)
{code}
public void removeFromParent() {
if (this.parent != null) {
ListQueryNode parentChildren = this.parent.getChildren();
IteratorQueryNode it = parentChildren.iterator();
while (it.hasNext()) {
if (it.next() == this) {
it.remove();
}
}
this.parent = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7628) Investigate not using apacheds-all jar
[ https://issues.apache.org/jira/browse/SOLR-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7628: - Attachment: SOLR-7628v2.patch Updated patch, correct order in lucene versions file. Investigate not using apacheds-all jar -- Key: SOLR-7628 URL: https://issues.apache.org/jira/browse/SOLR-7628 Project: Solr Issue Type: Bug Components: SolrCloud, Tests Affects Versions: 5.1, 6 Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7628.patch, SOLR-7628v2.patch Over in SOLR-6915 it was reported that using the apacheds-all jar can be an issue because it has some conflicting classes: bq. This apacheds-all jar seems troublesome - currently it has conflicting slf4j classes in it... See: https://issues.apache.org/jira/browse/SOLR-6915?focusedCommentId=14569870page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14569870 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 12775 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12775/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.search.TestSearcherReuse.test
Error Message:
expected same:Searcher@12fc776d[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.3.0):c4)))}
was not:Searcher@3f53d594[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.3.0):c4)))}
Stack Trace:
java.lang.AssertionError: expected same:Searcher@12fc776d[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.3.0):c4)))}
was not:Searcher@3f53d594[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(5.3.0):c4)))}
at
__randomizedtesting.SeedInfo.seed([88F1728F29DB7D6:80DB28F25C61DA2E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at org.junit.Assert.assertSame(Assert.java:593)
at
org.apache.solr.search.TestSearcherReuse.assertSearcherHasNotChanged(TestSearcherReuse.java:247)
at
org.apache.solr.search.TestSearcherReuse.test(TestSearcherReuse.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
[jira] [Updated] (SOLR-7458) Expose HDFS Block Locality Metrics
[ https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-7458: Attachment: SOLR-7458.patch Expose HDFS Block Locality Metrics -- Key: SOLR-7458 URL: https://issues.apache.org/jira/browse/SOLR-7458 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mike Drob Assignee: Mark Miller Labels: metrics Attachments: Data Locality.png, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch, SOLR-7458.patch We should publish block locality metrics when using HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7534) Handle internationalized quotes in queries
[ https://issues.apache.org/jira/browse/SOLR-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575344#comment-14575344 ] Jan Høydahl commented on SOLR-7534: --- Sure. Also have a customer facing problems with variants of '. You have ` and ´ and probably more as well, which may cause differences in how tokens are split up etc. Handle internationalized quotes in queries -- Key: SOLR-7534 URL: https://issues.apache.org/jira/browse/SOLR-7534 Project: Solr Issue Type: Improvement Reporter: Dawid Weiss Priority: Minor This is real feedback from a customer: bq. Don't talk to me about “ and as this is the number one problem we have with people composing SOLR phrase queries. It's kind of funny at first... until you realize how many different quote characters are out there and that many applications (for example Microsoft Word) automatically convert standard ASCII quotes into locale-sensitive unicode variants (examples on blogs, documentation, etc.). Perhaps there's a way to parse those various quote characters with some leniency? http://en.wikipedia.org/wiki/Quotation_mark#Summary_table_for_all_languages -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Artifacts-5.2 - Build # 11 - Still Failing
Build: https://builds.apache.org/job/Lucene-Artifacts-5.2/11/ No tests ran. Build Log: [...truncated 253 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Solr-Artifacts-5.x - Build # 850 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/850/ No tests ran. Build Log: [...truncated 260 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520)
[JENKINS] Solr-Artifacts-5.2 - Build # 13 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.2/13/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Solr-Artifacts-trunk - Build # 2573 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2573/ No tests ran. Build Log: [...truncated 260 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520) ... 35 more Caused by: java.net.ConnectException:
[JENKINS] Solr-Artifacts-5.x - Build # 851 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.x/851/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520)
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_45) - Build # 12953 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12953/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([5D3BAF950901DFF9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 9696 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2 Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.HttpPartitionTest 5D3BAF950901DFF9-001/init-core-data-001 [junit4] 2 224224 INFO (SUITE-HttpPartitionTest-seed#[5D3BAF950901DFF9]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 224226 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 224226 INFO (Thread-861) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 224226 INFO (Thread-861) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 224326 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.ZkTestServer start zk server on port:60430 [junit4] 2 224326 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 224327 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 224329 INFO (zkCallback-344-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@924b9c name:ZooKeeperConnection Watcher:127.0.0.1:60430 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 224329 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 224329 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 224329 INFO (TEST-HttpPartitionTest.test-seed#[5D3BAF950901DFF9]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2 224331 INFO
[JENKINS] Lucene-Artifacts-5.x - Build # 872 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/872/ No tests ran. Build Log: [...truncated 253 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Artifacts-5.2 - Build # 12 - Still Failing
Build: https://builds.apache.org/job/Lucene-Artifacts-5.2/12/ No tests ran. Build Log: [...truncated 6 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 703 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/703/ 2 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=103900, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=103900, name=collection3, state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:38431/ffy/jd: Could not find collection : awholynewstresscollection_collection3_3 at __randomizedtesting.SeedInfo.seed([53E1724000EACB53]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:902) FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=10837, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=10837, name=collection3, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:60497: collection already exists: awholynewstresscollection_collection3_2 at __randomizedtesting.SeedInfo.seed([53E1724000EACB53]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1570) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1591) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895) Build Log: [...truncated 10829 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest [junit4] 2 Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest 53E1724000EACB53-001/init-core-data-001 [junit4] 2 1545005 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[53E1724000EACB53]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) [junit4] 2 1545005 INFO (SUITE-CollectionsAPIDistributedZkTest-seed#[53E1724000EACB53]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 1545008 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[53E1724000EACB53]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 1545009 INFO (Thread-6700) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 1545009 INFO (Thread-6700) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 1545109 INFO (TEST-CollectionsAPIDistributedZkTest.test-seed#[53E1724000EACB53]) [] o.a.s.c.ZkTestServer start zk server on port:56247 [junit4] 2
ASF Policeman Jenkins jobs disabled [was: Re: [JENKINS] Solr-Artifacts-5.2 - Build # 13 - Still Failing]
ASF Infrastructure wrote in an email to committ...@apache.org that Subversion will be down for as much as 6 hours from 22:00 UTC. I temporarily took all three Policeman Jenkins nodes offline. I apparently don’t have such permission on ASF Jenkins, so I instead manually disabled all 19 jobs. I’ll re-enable things once Subversion is back up, if I’m still awake. Otherwise, anybody else should please feel free to do the same. Steve On Jun 5, 2015, at 6:56 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Solr-Artifacts-5.2/13/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #957: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/957/ No tests ran. Build Log: [...truncated 258 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 867 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/867/ No tests ran. Build Log: [...truncated 123 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 41 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/41/ No tests ran. Build Log: [...truncated 254 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520) ... 35 more Caused by: java.net.ConnectException:
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_45) - Build # 4773 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4773/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.test Error Message: SPLITSHARD was not successful even after three tries Stack Trace: java.lang.AssertionError: SPLITSHARD was not successful even after three tries at __randomizedtesting.SeedInfo.seed([2D46325723403F33:A5120D8D8DBC52CB]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.ShardSplitTest.splitByRouteFieldTest(ShardSplitTest.java:289) at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3193 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3193/ No tests ran. Build Log: [...truncated 4 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-Tests-5.2-Java7 - Build # 34 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.2-Java7/34/ No tests ran. Build Log: [...truncated 4 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1454: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1454/ No tests ran. Build Log: [...truncated 258 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520) ... 35 more Caused by: java.net.ConnectException:
[JENKINS] Lucene-Solr-NightlyTests-5.2 - Build # 12 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.2/12/ No tests ran. Build Log: [...truncated 123 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Artifacts-trunk - Build # 2680 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-trunk/2680/ No tests ran. Build Log: [...truncated 253 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:520) ... 35 more Caused by: java.net.ConnectException:
[JENKINS] Solr-Artifacts-5.2 - Build # 12 - Still Failing
Build: https://builds.apache.org/job/Solr-Artifacts-5.2/12/ No tests ran. Build Log: [...truncated 260 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: connection refused by the server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 42 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/42/ No tests ran. Build Log: [...truncated 4 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514) ... 35 more Caused by: java.net.SocketTimeoutException:
[jira] [Updated] (LUCENE-6529) NumericFields + SlowCompositeReaderWrapper + UninvertedReader + -Dtests.codec=random can results in incorrect SortedSetDocValues
[
https://issues.apache.org/jira/browse/LUCENE-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-6529:
-
Attachment: LUCENE-6529.patch
see patch for test case, a couple of example seeds that fail for me...
{noformat}
ant test -Dtestcase=TestUninvertingReader
-Dtests.method=testSortedSetIntegerManyValues -Dtests.seed=3A8A592786F36F30
-Dtests.slow=true -Dtests.asserts=true
ant test -Dtestcase=TestUninvertingReader
-Dtests.method=testSortedSetIntegerManyValues -Dtests.seed=C7B1C0FEDB6252C4
-Dtests.slow=true -Dtests.locale=ar_BH -Dtests.timezone=Asia/Yakutsk
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
ant test -Dtestcase=TestUninvertingReader
-Dtests.method=testSortedSetIntegerManyValues -Dtests.seed=6C6936440B92E593
-Dtests.slow=true -Dtests.locale=de_GR -Dtests.timezone=Atlantic/Bermuda
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
{noformat}
But you can find lots more fairely quickly with...
{noformat}
ant beast -Dbeast.iters=100 -Dtestcase=TestUninvertingReader
-Dtests.method=testSortedSetIntegerManyValues -Dtests.slow=true
-Dtests.asserts=true -Dtests.codec=random
{noformat}
Meanwhile this never fails on me...
{noformat}
ant beast -Dbeast.iters=100 -Dtestcase=TestUninvertingReader
-Dtests.method=testSortedSetIntegerManyValues -Dtests.slow=true
-Dtests.asserts=true -Dtests.codec=default
{noformat}
NumericFields + SlowCompositeReaderWrapper + UninvertedReader +
-Dtests.codec=random can results in incorrect SortedSetDocValues
-
Key: LUCENE-6529
URL: https://issues.apache.org/jira/browse/LUCENE-6529
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
Attachments: LUCENE-6529.patch
Digging into SOLR-7631 and SOLR-7605 I became fairly confident that the only
explanation of the behavior i was seeing was some sort of bug in either the
randomized codec/postings-format or the UninvertedReader, that was only
evident when two were combined and used on a multivalued Numeric Field using
precision steps. But since i couldn't find any -Dtests.codec or
-Dtests.postings.format options that would cause the bug 100% regardless of
seed, I switched tactices and focused on reproducing the problem using
UninvertedReader directly and checking the SortedSetDocValues.getValueCount().
I now have a test that fails frequently (and consistently for any seed i
find), but only with -Dtests.codec=random -- override it with
-Dtests.codec=default and everything works fine (based on the exhaustive
testing I did in the linked issues, i suspect every named codec works fine -
but i didn't re-do that testing here)
The failures only seem to happen when checking the
SortedSetDocValues.getValueCount() of a SlowCompositeReaderWrapper around the
UninvertedReader -- which suggests the root bug may actually be in
SlowCompositeReaderWrapper? (but still has some dependency on the random
codec)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7643) Function queries don't support hash # in field name
[ https://issues.apache.org/jira/browse/SOLR-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-7643. -- Resolution: Invalid First of all, please raise issues like this on the user's list first, and if there's any consensus that this is a code issue, _then_ raise a JIRA. In this case, the recommendation has always been that field names follow Java naming conventions, see: https://wiki.apache.org/solr/SchemaXml the Fields section. Function queries don't support hash # in field name - Key: SOLR-7643 URL: https://issues.apache.org/jira/browse/SOLR-7643 Project: Solr Issue Type: Bug Components: SolrJ Affects Versions: 4.7.2 Reporter: DAG Support Priority: Minor I have some index documents with both table_name and #table_name fields. If I use a function query with table_name: SolrQuery query = new SolrQuery(); query.add(fl , exists(table_name)); it works, returning results like this: docbool name=exists(table_name)true/bool/doc However, if I use #table_name: query.add(fl , exists(#table_name)); it returns empty documents like this: doc/doc -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 12955 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12955/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.DistributedVersionInfoTest.test Error Message: Captured an uncaught exception in thread: Thread[id=3412, name=Thread-1570, state=RUNNABLE, group=TGRP-DistributedVersionInfoTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=3412, name=Thread-1570, state=RUNNABLE, group=TGRP-DistributedVersionInfoTest] at __randomizedtesting.SeedInfo.seed([99DC275F41038CE8:11881885EFFFE110]:0) Caused by: java.lang.IllegalArgumentException: bound must be positive at __randomizedtesting.SeedInfo.seed([99DC275F41038CE8]:0) at java.util.Random.nextInt(Random.java:388) at org.apache.solr.cloud.DistributedVersionInfoTest$3.run(DistributedVersionInfoTest.java:197) Build Log: [...truncated 9863 lines...] [junit4] Suite: org.apache.solr.cloud.DistributedVersionInfoTest [junit4] 2 Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.DistributedVersionInfoTest 99DC275F41038CE8-001/init-core-data-001 [junit4] 2 397919 INFO (SUITE-DistributedVersionInfoTest-seed#[99DC275F41038CE8]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2 397921 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2 397922 INFO (Thread-1485) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2 397922 INFO (Thread-1485) [] o.a.s.c.ZkTestServer Starting server [junit4] 2 398022 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.ZkTestServer start zk server on port:46600 [junit4] 2 398022 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 398022 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 398027 INFO (zkCallback-305-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@7e7197c6 name:ZooKeeperConnection Watcher:127.0.0.1:46600 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 398027 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 398027 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 398027 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2 398033 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2 398053 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2 398068 INFO (zkCallback-306-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@3d33c7d7 name:ZooKeeperConnection Watcher:127.0.0.1:46600/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2 398068 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2 398069 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2 398069 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1 [junit4] 2 398071 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards [junit4] 2 398071 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient makePath: /collections/control_collection [junit4] 2 398072 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards [junit4] 2 398073 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2 398073 INFO (TEST-DistributedVersionInfoTest.test-seed#[99DC275F41038CE8]) []
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3194 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3194/ No tests ran. Build Log: [...truncated 3 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[jira] [Created] (LUCENE-6529) NumericFields + SlowCompositeReaderWrapper + UninvertedReader + -Dtests.codec=random can results in incorrect SortedSetDocValues
Hoss Man created LUCENE-6529: Summary: NumericFields + SlowCompositeReaderWrapper + UninvertedReader + -Dtests.codec=random can results in incorrect SortedSetDocValues Key: LUCENE-6529 URL: https://issues.apache.org/jira/browse/LUCENE-6529 Project: Lucene - Core Issue Type: Bug Reporter: Hoss Man Digging into SOLR-7631 and SOLR-7605 I became fairly confident that the only explanation of the behavior i was seeing was some sort of bug in either the randomized codec/postings-format or the UninvertedReader, that was only evident when two were combined and used on a multivalued Numeric Field using precision steps. But since i couldn't find any -Dtests.codec or -Dtests.postings.format options that would cause the bug 100% regardless of seed, I switched tactices and focused on reproducing the problem using UninvertedReader directly and checking the SortedSetDocValues.getValueCount(). I now have a test that fails frequently (and consistently for any seed i find), but only with -Dtests.codec=random -- override it with -Dtests.codec=default and everything works fine (based on the exhaustive testing I did in the linked issues, i suspect every named codec works fine - but i didn't re-do that testing here) The failures only seem to happen when checking the SortedSetDocValues.getValueCount() of a SlowCompositeReaderWrapper around the UninvertedReader -- which suggests the root bug may actually be in SlowCompositeReaderWrapper? (but still has some dependency on the random codec) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3195 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3195/ No tests ran. Build Log: [...truncated 3 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_5x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 34 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_5x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 35 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
[jira] [Commented] (SOLR-7643) Function queries don't support hash # in field name
[
https://issues.apache.org/jira/browse/SOLR-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575548#comment-14575548
]
Yonik Seeley commented on SOLR-7643:
I haven't tried it in this specific scenario, but there is also a field()
function to reference a problematic field name:
example: exists(field('#table_name'))
Function queries don't support hash # in field name
-
Key: SOLR-7643
URL: https://issues.apache.org/jira/browse/SOLR-7643
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 4.7.2
Reporter: DAG Support
Priority: Minor
I have some index documents with both table_name and #table_name fields.
If I use a function query with table_name:
SolrQuery query = new SolrQuery();
query.add(fl , exists(table_name));
it works, returning results like this: docbool
name=exists(table_name)true/bool/doc
However, if I use #table_name:
query.add(fl , exists(#table_name));
it returns empty documents like this: doc/doc
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: ASF Policeman Jenkins jobs disabled [was: Re: [JENKINS] Solr-Artifacts-5.2 - Build # 13 - Still Failing]
I took the Policeman Jenkins nodes back online, and jobs seem to be building fine there. However, after I re-enabled all the ASF Jenkins jobs, Subversion can’t update checkouts. For now I’m re-disabling all the ASF Jenkins jobs. Also, I can’t update or checkout locally. At Infra’s request on Hipchat, I created a JIRA: https://issues.apache.org/jira/browse/INFRA-9775 Steve On Jun 5, 2015, at 7:37 PM, Steve Rowe sar...@gmail.com wrote: ASF Infrastructure wrote in an email to committ...@apache.org that Subversion will be down for as much as 6 hours from 22:00 UTC. I temporarily took all three Policeman Jenkins nodes offline. I apparently don’t have such permission on ASF Jenkins, so I instead manually disabled all 19 jobs. I’ll re-enable things once Subversion is back up, if I’m still awake. Otherwise, anybody else should please feel free to do the same. Steve On Jun 5, 2015, at 6:56 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Solr-Artifacts-5.2/13/ No tests ran. Build Log: [...truncated 8 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_2 org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1030) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1011) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:987) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2474) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/lucene_solr_5_2 failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 35 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/lucene_solr_5_2' svn: E175002: connection refused by
[jira] [Commented] (LUCENE-6522) Reproducible fieldcache AIOOBE only on J9
[
https://issues.apache.org/jira/browse/LUCENE-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14575504#comment-14575504
]
Robert Muir commented on LUCENE-6522:
-
Hmm, I meant to include that:
{noformat}
java version 1.8.0
Java(TM) SE Runtime Environment (build pxa6480sr1-20150417_01(SR1))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
20150410_243669 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR1_20150410_1531_B243669
JIT - tr.r14.java_20150402_88976.03
GC - R28_Java8_SR1_20150410_1531_B243669_CMPRSS
J9CL - 20150410_243669)
JCL - 20150413_01 based on Oracle jdk8u45-b13
{noformat}
Reproducible fieldcache AIOOBE only on J9
-
Key: LUCENE-6522
URL: https://issues.apache.org/jira/browse/LUCENE-6522
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Haven't dug in yet, just:
* reproduces easily on J9
* does not happen on Oracle JVM
{noformat}
[junit4] Suite: org.apache.lucene.uninverting.TestFieldCacheVsDocValues
[junit4] IGNOR/A 0.51s J2 |
TestFieldCacheVsDocValues.testHugeBinaryValueLimit
[junit4] Assumption #1: test requires codec with limits on max binary
field length
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestFieldCacheVsDocValues
-Dtests.method=testSortedSetFixedLengthVsUninvertedField
-Dtests.seed=831619B333C362E6 -Dtests.locale=es_UY
-Dtests.timezone=Atlantic/Bermuda -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.54s J2 |
TestFieldCacheVsDocValues.testSortedSetFixedLengthVsUninvertedField
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException
[junit4] at
__randomizedtesting.SeedInfo.seed([831619B333C362E6:B6EC641493EA4AD3]:0)
[junit4] at
org.apache.lucene.uninverting.DocTermOrds$OrdWrappedTermsEnum.seekCeil(DocTermOrds.java:692)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:570)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:511)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.doTestSortedSetVsUninvertedField(TestFieldCacheVsDocValues.java:385)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.testSortedSetFixedLengthVsUninvertedField(TestFieldCacheVsDocValues.java:105)
[junit4] at java.lang.Thread.run(Thread.java:785)
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestFieldCacheVsDocValues
-Dtests.method=testSortedSetVariableLengthVsUninvertedField
-Dtests.seed=831619B333C362E6 -Dtests.locale=es_UY
-Dtests.timezone=Atlantic/Bermuda -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.42s J2 |
TestFieldCacheVsDocValues.testSortedSetVariableLengthVsUninvertedField
[junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException
[junit4] at
__randomizedtesting.SeedInfo.seed([831619B333C362E6:2AB51ED6D324E426]:0)
[junit4] at
org.apache.lucene.uninverting.DocTermOrds$OrdWrappedTermsEnum.seekCeil(DocTermOrds.java:692)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:570)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.assertEquals(TestFieldCacheVsDocValues.java:511)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.doTestSortedSetVsUninvertedField(TestFieldCacheVsDocValues.java:385)
[junit4] at
org.apache.lucene.uninverting.TestFieldCacheVsDocValues.testSortedSetVariableLengthVsUninvertedField(TestFieldCacheVsDocValues.java:112)
[junit4] at java.lang.Thread.run(Thread.java:785)
[junit4] 2 NOTE: leaving temporary files on disk at:
/home/rmuir/workspace/trunk-ibm/lucene/build/misc/test/J2/temp/lucene.uninverting.TestFieldCacheVsDocValues
831619B333C362E6-001
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene50):
{indexed=FSTOrd50, id=Lucene50(blocksize=128)},
docValues:{dv=DocValuesFormat(name=Asserting),
field=DocValuesFormat(name=Asserting)}, sim=DefaultSimilarity, locale=es_UY,
timezone=Atlantic/Bermuda
[junit4] 2 NOTE: Linux 3.13.0-49-generic amd64/IBM Corporation 1.8.0
(64-bit)/cpus=8,threads=1,free=10179616,total=32243712
[junit4] 2 NOTE: All tests run in this JVM: [TestDocTermOrds,
TestNumericTerms32, TestFieldCacheVsDocValues]
[junit4] Completed [21/25] on J2 in 4.50s, 10 tests, 2 errors, 1 skipped
FAILURES!
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail:
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 12956 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12956/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([54D327AB3E7DB2DB:BD899C93A0E42273]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770) at org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1] xml response was: ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime1/int/lstresult name=response numFound=0 start=0/result /response request
[jira] [Created] (LUCENE-6528) Sort by SortField.FIELD_SCORE produces NaN scores
Ahmet Arslan created LUCENE-6528: Summary: Sort by SortField.FIELD_SCORE produces NaN scores Key: LUCENE-6528 URL: https://issues.apache.org/jira/browse/LUCENE-6528 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 5.1 Reporter: Ahmet Arslan Explicit sort by document score/relevance (SortField.FIELD_SCORE) yields Not a Number (NaN) scores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6528) Sort by SortField.FIELD_SCORE produces NaN scores
[ https://issues.apache.org/jira/browse/LUCENE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ahmet Arslan updated LUCENE-6528: - Attachment: LUCENE-6528.patch A failing test case that demonstrates the bug. Sort by SortField.FIELD_SCORE produces NaN scores - Key: LUCENE-6528 URL: https://issues.apache.org/jira/browse/LUCENE-6528 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 5.1 Reporter: Ahmet Arslan Labels: sort Attachments: LUCENE-6528.patch Explicit sort by document score/relevance (SortField.FIELD_SCORE) yields Not a Number (NaN) scores. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5954) Store lucene version in segment_N
[ https://issues.apache.org/jira/browse/LUCENE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5954: --- Attachment: LUCENE-5954.patch New patch folding feedback in ... I think it's ready. Store lucene version in segment_N - Key: LUCENE-5954 URL: https://issues.apache.org/jira/browse/LUCENE-5954 Project: Lucene - Core Issue Type: Bug Reporter: Ryan Ernst Assignee: Michael McCandless Fix For: Trunk, 5.3 Attachments: LUCENE-5954.patch, LUCENE-5954.patch It would be nice to have the version of lucene that wrote segments_N, so that we can use this to determine which major version an index was written with (for upgrading across major versions). I think this could be squeezed in just after the segments_N header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5954) Store lucene version in segment_N
[ https://issues.apache.org/jira/browse/LUCENE-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5954: --- Fix Version/s: 5.3 Trunk Store lucene version in segment_N - Key: LUCENE-5954 URL: https://issues.apache.org/jira/browse/LUCENE-5954 Project: Lucene - Core Issue Type: Bug Reporter: Ryan Ernst Assignee: Michael McCandless Fix For: Trunk, 5.3 Attachments: LUCENE-5954.patch, LUCENE-5954.patch It would be nice to have the version of lucene that wrote segments_N, so that we can use this to determine which major version an index was written with (for upgrading across major versions). I think this could be squeezed in just after the segments_N header. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
