[jira] [Commented] (SOLR-10023) Improve single unit test run time with ant.

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15834023#comment-15834023
 ] 

Dawid Weiss commented on SOLR-10023:


Mark: try checking which task is taking so much time.
https://ant.apache.org/manual/listeners.html#ProfileLogger

Looks like it could be trying to load/ parse all the test classes, even if only 
one of them is executed? Shouldn't be the case if it's input fileset filtering 
for ant though, odd.

> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (SOLR-8733) versions=true on Optimistic Concurrency updates doesn't work with in multi shard collections

[Jun Wu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jun Wu updated SOLR-8733:
-
Comment: was deleted

(was: NO one cares this issue ?)

> versions=true on Optimistic Concurrency updates doesn't work with in multi 
> shard collections
> 
>
> Key: SOLR-8733
> URL: https://issues.apache.org/jira/browse/SOLR-8733
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8733_incomplete_test.patch, 
> TestReturnedVersions.java
>
>
> Noticed this while working on SOLR-445...
> the {{versions=true}} param is documented as an option that can be used when 
> doing updates if you care about opportunistic concurrency so that you know 
> for certain which {{_version_}} was associated with each update you send, w/o 
> needing to issue a subsequent {{/get}} request for the updated documents 
> (which might return some _newer_ version if another client did an update 
> immediately after you...
> https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents
> Ironically, even though DistributedUpdateProcessor is where all of the 
> opportunistic concurrency code lives, and the logic for {{versions=true}} is 
> handled, it does nothing to ensure that the results are populated when 
> requests are forwarded to other leaders - instead, the code seems to just 
> assume all updates have their version assigned locally, so they wind up being 
> "0" ...
> Single node example of it working properly...
> {noformat}
> $ bin/solr -e techproducts -noprompt
> ...
> $ curl -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/techproducts/update?versions=true' --data-binary 
> '[{"id":"abc!111","foo_s":"one"}, {"id":"XYZ!222","foo_s":"two"}]'
> {"responseHeader":{"status":0,"QTime":10},"adds":["abc!111",1527095970400043008,"XYZ!222",1527095970402140160]}
> {noformat}
> Multinode multi-shard example of current broken behavior...
> {noformat}
> $ bin/solr -e cloud -noprompt
> ...
> $ curl -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/gettingstarted/update?versions=true' 
> --data-binary '[{"id":"abc!111","foo_s":"one"}, 
> {"id":"XYZ!222","foo_s":"two"}]'
> {"responseHeader":{"status":0,"QTime":32},"adds":["abc!111",0,"XYZ!222",0]}
> {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] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833767#comment-15833767
 ] 

Ishan Chattopadhyaya edited comment on SOLR-5944 at 1/23/17 7:13 AM:
-

{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

-Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.-


Edit: I just did 12 runs (3 on 5944, then 3 on master, then 3 on 5944, then 3 
on master).
Here are the results of the 12 runs, and average per branch:

||Branch||1||2||3||4||5||6||7||8||9||10||11||12||Avg||
|master| | | |652|671|676| | | |701|667|628||666||
|5944|656|661|676| | | |656|652|664| | | ||661||

I think these differences are just due to statistical noise, and there is no 
significant speedup/slowdown for the non-dv updates.

[0] - https://gist.github.com/chatman/c085af9d1ea9d9e2c56d037e0c6ab119


was (Author: ichattopadhyaya):
{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

-Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.-


Edit: I just did 12 runs (3 on 5944, then 3 on master, then 3 on 5944, then 3 
on master).
Here are the results of the 12 runs, and average per branch:

||Branch||1|2|3|4|5|6|7|8|9|10|11|12|Avg||
|master| | | |652|671|676| | | |701|667|628|666|
|5944|656|661|676| | | |656|652|664| | | |661|

I think these differences are just due to statistical noise, and there is no 
significant speedup/slowdown for the non-dv updates.

[0] - https://gist.github.com/chatman/c085af9d1ea9d9e2c56d037e0c6ab119

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833767#comment-15833767
 ] 

Ishan Chattopadhyaya edited comment on SOLR-5944 at 1/23/17 7:11 AM:
-

{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

-Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.-


Edit: I just did 12 runs (3 on 5944, then 3 on master, then 3 on 5944, then 3 
on master).
Here are the results of the 12 runs, and average per branch:

||Branch||1|2|3|4|5|6|7|8|9|10|11|12|Avg||
|master| | | |652|671|676| | | |701|667|628|666|
|5944|656|661|676| | | |656|652|664| | | |661|

I think these differences are just due to statistical noise, and there is no 
significant speedup/slowdown for the non-dv updates.

[0] - https://gist.github.com/chatman/c085af9d1ea9d9e2c56d037e0c6ab119


was (Author: ichattopadhyaya):
{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.

[0] - https://gist.github.com/chatman/c085af9d1ea9d9e2c56d037e0c6ab119

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
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-SmokeRelease-master - Build # 682 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/682/

No tests ran.

Build Log:
[...truncated 41925 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (25.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 30.5 MB in 0.03 sec (1104.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 65.0 MB in 0.06 sec (1078.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 75.3 MB in 0.07 sec (1056.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6204 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6204 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   6.4.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1474, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1418, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1456, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 768, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:571:
 exec returned: 1

Total time: 39 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
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

[JENKINS] Lucene-Solr-Tests-master - Build # 1632 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1632/

1 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=15634, 
name=SocketProxy-Response-33733:46186, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=15634, name=SocketProxy-Response-33733:46186, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([2EEB55666F4D3720:A6BF6ABCC1B15AD8]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([2EEB55666F4D3720]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1137)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)




Build Log:
[...truncated 11984 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_2EEB55666F4D3720-001/init-core-data-001
   [junit4]   2> 895207 INFO  
(SUITE-HttpPartitionTest-seed#[2EEB55666F4D3720]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields
   [junit4]   2> 895208 INFO  
(SUITE-HttpPartitionTest-seed#[2EEB55666F4D3720]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 895209 INFO  
(SUITE-HttpPartitionTest-seed#[2EEB55666F4D3720]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /spc/mc
   [junit4]   2> 895210 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 895210 INFO  (Thread-4216) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 895211 INFO  (Thread-4216) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 895310 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.ZkTestServer start zk server on port:45064
   [junit4]   2> 895323 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 895324 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 895325 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 895326 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 895327 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 895328 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 895329 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 895330 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 895331 INFO  
(TEST-HttpPartitionTest.test-seed#[2EEB55666F4D3720]) [] 
o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt
 to 

[jira] [Updated] (SOLR-10024) If you use ExternalPaths#determineSourceHome with a custom tests.workDir, tests may not find the path.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-10024:
---
Attachment: SOLR-10024.patch

> If you use ExternalPaths#determineSourceHome with a custom tests.workDir, 
> tests may not find the path.
> --
>
> Key: SOLR-10024
> URL: https://issues.apache.org/jira/browse/SOLR-10024
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-10024.patch
>
>
> As the comments say, this is already kind of an ugly hack, and if you change 
> the test working dir it won't be able to find the source tree and a slew of 
> tests won't work. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10024) If you use ExternalPaths#determineSourceHome with a custom tests.workDir, tests may not find the path.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833924#comment-15833924
 ] 

Mark Miller commented on SOLR-10024:


This tries to use the current working directory to find the src, but when using 
ant that can be moved around (one use is for parallel tests). In this case, 
tests.workDir may not fall under the src tree, and null will be returned.

This patch improves on this by passing a new system property with the ant 
current working directory and determineSourceHome will first look for that 
system property, else do what is has been doing.

> If you use ExternalPaths#determineSourceHome with a custom tests.workDir, 
> tests may not find the path.
> --
>
> Key: SOLR-10024
> URL: https://issues.apache.org/jira/browse/SOLR-10024
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> As the comments say, this is already kind of an ugly hack, and if you change 
> the test working dir it won't be able to find the source tree and a slew of 
> tests won't work. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10024) If you use ExternalPaths#determineSourceHome with a custom tests.workDir, tests may not find the path.

[Mark Miller (JIRA)]

Mark Miller created SOLR-10024:
--

 Summary: If you use ExternalPaths#determineSourceHome with a 
custom tests.workDir, tests may not find the path.
 Key: SOLR-10024
 URL: https://issues.apache.org/jira/browse/SOLR-10024
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Miller
Assignee: Mark Miller


As the comments say, this is already kind of an ugly hack, and if you change 
the test working dir it won't be able to find the source tree and a slew of 
tests won't work. 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6365 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6365/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.PeerSyncReplicationTest.test

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([951412F9825961A9:1D402D232CA50C51]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 18826 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18826/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting

Error Message:
Should have exactly 4 documents returned expected:<4> but was:<3>

Stack Trace:
java.lang.AssertionError: Should have exactly 4 documents returned expected:<4> 
but was:<3>
at 
__randomizedtesting.SeedInfo.seed([ACF17590CB60B8A8:B2C97D98B7CB0228]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.checkSortOrder(DocValuesNotIndexedTest.java:259)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting(DocValuesNotIndexedTest.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 243 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/243/

No tests ran.

Build Log:
[...truncated 41924 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (32.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.5.0-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1140.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.tgz...
   [smoker] 65.1 MB in 0.06 sec (1142.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.zip...
   [smoker] 75.5 MB in 0.07 sec (1138.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6220 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6220 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 231 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1472, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1416, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1454, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 768, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1392, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker]   6.4.0
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/build.xml:571: 
exec returned: 1

Total time: 40 minutes 9 seconds
Build step 'Invoke Ant' marked build as failure
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] [Created] (LUCENE-7652) LRUQueryCache / IndexSearcher.DEFAULT_QUERY_CACHE memory leak

[Lae (JIRA)]

Lae created LUCENE-7652:
---

 Summary: LRUQueryCache / IndexSearcher.DEFAULT_QUERY_CACHE memory 
leak
 Key: LUCENE-7652
 URL: https://issues.apache.org/jira/browse/LUCENE-7652
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 5.5, 5.4
Reporter: Lae
Priority: Critical


Our {{IndexSearcher.DEFAULT_QUERY_CACHE}} is set to use 32MB of heap (the 
default), however upon inspection of our application's heap, it's retaining 
~280MB of memory and increasing slowly.

{{LRUQueryCache.cache.size}} was at 12,099, and 
{{LRUQueryCache.cache.modCount}} was also 12,099, meaning nothing was removed 
from {{LRUQueryCache.cache}} at all.

The keys of {{LRUQueryCache.cache}} are instances of {{SegmentCoreReaders}}, 
and I've checked many of the keys, the only reference to them is 
{{LRUQueryCache.cache}}, given {{LRUQueryCache.cache}} is an 
{{IdentityHashMap}}, that means you can't even get to them outside of the cache 
because you can't get a key that's equivalent to one of these in the cache.

This affectively makes {{IndexSearcher.DEFAULT_QUERY_CACHE}} a memory black 
hole.




--
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-10023) Improve single unit test run time with ant.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833841#comment-15833841
 ] 

Mark Miller commented on SOLR-10023:


It's also interesting that the bulk of the time appears to be after the test 
has finished, and only if it's successful. Must be some way to speed this up.

> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-10023) Improve single unit test run time with ant.

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833827#comment-15833827
 ] 

David Smiley commented on SOLR-10023:
-

+1 yes, it takes way too long right now.

> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-7191) Improve stability and startup performance of SolrCloud with thousands of collections

[Damien Kamerman (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833804#comment-15833804
 ] 

Damien Kamerman commented on SOLR-7191:
---

Regarding the extra threads, I'm thinking the issue is that 
CoreContainer.load() now calls ZkContainer.registerInZk() with background 
'true'. Check how many 'coreZkRegister' threads there are.

> Improve stability and startup performance of SolrCloud with thousands of 
> collections
> 
>
> Key: SOLR-7191
> URL: https://issues.apache.org/jira/browse/SOLR-7191
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Noble Paul
>  Labels: performance, scalability
> Fix For: 6.3
>
> Attachments: lots-of-zkstatereader-updates-branch_5x.log, 
> SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch, 
> SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch
>
>
> A user on the mailing list with thousands of collections (5000 on 4.10.3, 
> 4000 on 5.0) is having severe problems with getting Solr to restart.
> I tried as hard as I could to duplicate the user setup, but I ran into many 
> problems myself even before I was able to get 4000 collections created on a 
> 5.0 example cloud setup.  Restarting Solr takes a very long time, and it is 
> not very stable once it's up and running.
> This kind of setup is very much pushing the envelope on SolrCloud performance 
> and scalability.  It doesn't help that I'm running both Solr nodes on one 
> machine (I started with 'bin/solr -e cloud') and that ZK is embedded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 264 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/264/

3 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_stored_idx

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([FF2C59EBCF29AB96:EF4DF412DA8BEEB8]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.waitForRecoveriesToFinish(TestStressCloudBlindAtomicUpdates.java:459)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:304)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_stored_idx(TestStressCloudBlindAtomicUpdates.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10023) Improve single unit test run time with ant.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833795#comment-15833795
 ] 

Mark Miller commented on SOLR-10023:


[~steve_rowe], I cannot remember who was involved in a lot of the latest build 
system design, but for some reason your name comes to mind as someone involved. 
If so, do you recall this issue and if any attempt to improve on it was made?

> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-10023) Improve single unit test run time with ant.

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833794#comment-15833794
 ] 

Ishan Chattopadhyaya commented on SOLR-10023:
-

+1 to solving this. This is a huge pain point.

> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-10023) Improve single unit test run time with ant.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-10023:
---
Description: 
It seems to take 2 minutes and 45 seconds to run a single test with the latest 
build design and the test itself is only 4 seconds. I've noticed this for a 
long time, and it seems because ant is running through a billion targets first. 

I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
Lucene and move this issue if necessary.

There is hopefully something we can do to improve this though. At least we 
should try and get some sharp minds to take first / second look. If I did not 
use an IDE so much to run tests, this would drive me nuts.

  was:
It seems to take 2 minutes and 45 seconds to run a single test with the latest 
build design. I've noticed this for a long time, and it seems because ant is 
running through a billion targets first. 

I haven't check yet, so maybe it's a Solr specific issue? I'll check with 
Lucene and move this issue if necessary.

There is hopefully something we can do to improve this though. At least we 
should try and get some sharp minds to take first / second look. If I did not 
use an IDE so much to run tests, this would drive me nuts.


> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design and the test itself is only 4 seconds. I've noticed this 
> for a long time, and it seems because ant is running through a billion 
> targets first. 
> I haven't checked yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-10023) Improve single unit test run time with ant.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-10023:
---
Description: 
It seems to take 2 minutes and 45 seconds to run a single test with the latest 
build design. I've noticed this for a long time, and it seems because ant is 
running through a billion targets first. 

I haven't check yet, so maybe it's a Solr specific issue? I'll check with 
Lucene and move this issue if necessary.

There is hopefully something we can do to improve this though. At least we 
should try and get some sharp minds to take first / second look. If I did not 
use an IDE so much to run tests, this would drive me nuts.

  was:
It seems to take 2 minutes and 45 seconds to run a single test with the latest 
build design. I've noticed this for a long time, and it seems because ant is 
running through a billion targets first. 

I haven't check yet, so maybe it's a Solr specific issue? I'll check with 
Lucene and move this issue if necessary.

There is hopefully something we can to improve this though. At least we should 
try and get some sharp minds to take first / second look.


> Improve single unit test run time with ant.
> ---
>
> Key: SOLR-10023
> URL: https://issues.apache.org/jira/browse/SOLR-10023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>
> It seems to take 2 minutes and 45 seconds to run a single test with the 
> latest build design. I've noticed this for a long time, and it seems because 
> ant is running through a billion targets first. 
> I haven't check yet, so maybe it's a Solr specific issue? I'll check with 
> Lucene and move this issue if necessary.
> There is hopefully something we can do to improve this though. At least we 
> should try and get some sharp minds to take first / second look. If I did not 
> use an IDE so much to run tests, this would drive me nuts.



--
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-10023) Improve single unit test run time with ant.

[Mark Miller (JIRA)]

Mark Miller created SOLR-10023:
--

 Summary: Improve single unit test run time with ant.
 Key: SOLR-10023
 URL: https://issues.apache.org/jira/browse/SOLR-10023
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Mark Miller


It seems to take 2 minutes and 45 seconds to run a single test with the latest 
build design. I've noticed this for a long time, and it seems because ant is 
running through a billion targets first. 

I haven't check yet, so maybe it's a Solr specific issue? I'll check with 
Lucene and move this issue if necessary.

There is hopefully something we can to improve this though. At least we should 
try and get some sharp minds to take first / second look.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1091 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1091/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
  at sun.reflect.GeneratedConstructorAccessor125.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:755)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:817)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1067)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:932)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:825)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:927)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:571)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102)
at sun.reflect.GeneratedConstructorAccessor125.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:755)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:817)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1067)
at org.apache.solr.core.SolrCore.(SolrCore.java:932)
at org.apache.solr.core.SolrCore.(SolrCore.java:825)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:927)
at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:571)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([B47179DEFA09D67B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:289)
at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833767#comment-15833767
 ] 

Ishan Chattopadhyaya edited comment on SOLR-5944 at 1/23/17 12:22 AM:
--

{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.

[0] - https://gist.github.com/chatman/c085af9d1ea9d9e2c56d037e0c6ab119


was (Author: ichattopadhyaya):
{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
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-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833767#comment-15833767
 ] 

Ishan Chattopadhyaya commented on SOLR-5944:


{code}
In this version of the script [0], the exact same 20K documents are added, and 
the script still does 
50 iterations of 5K updates – but this time only to the stored+indexed long 
field...
{code}

Hoss' results, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||stored+indexed Updates||
|master|49|521|
|5944|50|527|

My results:
||Branch||Adds||stored+indexed Updates||
|master|37|603|
|5944|38|637|

Seems like a 1% (Hoss) and 5% (my) slowdown in the regular non-dv updates from 
master to 5944. Will try to dig deeper to see if this slowdown can be 
avoided/reduced.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
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-9759) Admin UI should post streaming expressions

[Gus Heck (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833731#comment-15833731
 ] 

Gus Heck commented on SOLR-9759:


One work around (hack) is to edit etc/jetty.xml and change 
{code}

 {code}
to something larger... 
{code}

 {code}

> Admin UI should post streaming expressions
> --
>
> Key: SOLR-9759
> URL: https://issues.apache.org/jira/browse/SOLR-9759
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.2.1
>Reporter: Gus Heck
>
> Haven't had the chance to test this in 6.3, but in 6.2.1 I just ran into 
> request entity too large, when I pasted an expression into the admin ui to 
> begin debugging it... 
> Furthermore, the UI gives no indication of any error at all, leading one to 
> sit, waiting for the response. Firefox JavaScript console shows a 413 
> response and this:
> {code}
> 11:01:11.095 Error: JSON.parse: unexpected character at line 1 column 1 of 
> the JSON data
> $scope.doStream/<@http://localhost:8984/solr/js/angular/controllers/stream.js:48:24
> v/http://localhost:8984/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8984/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8984/solr/libs/angular.js:13209:27
> $RootScopeProvider/this.$gethttp://localhost:8984/solr/libs/angular.js:14406:16
> $RootScopeProvider/this.$gethttp://localhost:8984/solr/libs/angular.js:14222:15
> $RootScopeProvider/this.$gethttp://localhost:8984/solr/libs/angular.js:14511:13
> done@http://localhost:8984/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8984/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8984/solr/libs/angular.js:9800:9
> 1angular.js:11617:18
> consoleLog/<()angular.js:11617
> $ExceptionHandlerProvider/this.$get processQueue()angular.js:13201
> scheduleProcessQueue/<()angular.js:13209
> $RootScopeProvider/this.$get $RootScopeProvider/this.$get $RootScopeProvider/this.$get done()angular.js:9669
> completeRequest()angular.js:9859
> requestLoaded()angular.js:9800
> {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

RE: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3791 - Still Failing!

[Uwe Schindler]

I fixed the lock file problem.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Sunday, January 22, 2017 10:54 PM
> To: u...@thetaphi.de; dev@lucene.apache.org
> Subject: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3791
> - Still Failing!
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3791/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
> 
> All tests passed
> 
> Build Log:
> [...truncated 9954 lines...]
> BUILD FAILED
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:775: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:719: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:59: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:252:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-
> build.xml:536: The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-
> build.xml:484: The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-
> build.xml:385: The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-
> MacOSX/solr/core/build.xml:65: impossible to resolve dependencies:
>   resolve failed - see output for details
> 
> Total time: 45 minutes 0 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3791 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3791/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 9954 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:775: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:719: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:59: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:252: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:536: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:484: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:385: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/build.xml:65: 
impossible to resolve dependencies:
resolve failed - see output for details

Total time: 45 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9983) TestManagedSchemaThreadSafety.testThreadSafety() failures

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9983:
---
Fix Version/s: 6.5
   master (7.0)

> TestManagedSchemaThreadSafety.testThreadSafety() failures
> -
>
> Key: SOLR-9983
> URL: https://issues.apache.org/jira/browse/SOLR-9983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: master (7.0)
>Reporter: Steve Rowe
>Assignee: Mikhail Khludnev
> Fix For: master (7.0), 6.5
>
> Attachments: SOLR-9983-connection-loss-retry.patch, SOLR-9983.patch, 
> tests-failures-TestManagedSchemaThreadSafety-724.txt
>
>
> I set up a Jenkins job to hammer all tests on the {{jira/solr-5944}} branch, 
> and at least four times this test failed (none of the seeds reproduce for 
> me): [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/155/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/167/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/106/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/332/].  My email search 
> didn't turn up any failures on ASF or Policeman Jenkins. Here's the output 
> from one of the above runs:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestManagedSchemaThreadSafety -Dtests.method=testThreadSafety 
> -Dtests.seed=3DB2B79301AA806B -Dtests.slow=true -Dtests.locale=lt 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   4.37s J4  | 
> TestManagedSchemaThreadSafety.testThreadSafety <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: org.apache.solr.common.SolrException: Error 
> loading solr config from solrconfig.xml
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3DB2B79301AA806B:A7F8A3CBD235329D]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.testThreadSafety(TestManagedSchemaThreadSafety.java:126)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: 
> org.apache.solr.common.SolrException: Error loading solr config from 
> solrconfig.xml
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.lambda$indexSchemaLoader$0(TestManagedSchemaThreadSafety.java:159)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: org.apache.solr.common.SolrException: Error 
> loading solr config from solrconfig.xml
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:187)
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.lambda$indexSchemaLoader$0(TestManagedSchemaThreadSafety.java:152)
>[junit4]>  ... 6 more
>[junit4]> Caused by: java.lang.NullPointerException
>[junit4]>  at 
> org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:99)
>[junit4]>  at 
> org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:361)
>[junit4]>  at org.apache.solr.core.Config.(Config.java:120)
>[junit4]>  at org.apache.solr.core.Config.(Config.java:90)
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.(SolrConfig.java:202)
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:179)
>[junit4]>  ... 7 more
> {noformat}
> Looks to me like this is a test bug: the test mocks {{ZkController}}, but the 
> mock returns null for (the uninitialized {{cc}} returned by) 
> {{getCoreContainer()}}, which is called when the ZK session expires in 
> {{ZkSolrResourceLoader.openResource()}}.  The NPE is triggered when 
> {{isShutdown()}} is called on the null core container:
> {code:java|title=ZkSolrResourceLoader.java}
>  97: } catch (KeeperException.SessionExpiredException e) {
>  98:   exception = e;
>  99:   if 

[jira] [Assigned] (SOLR-9983) TestManagedSchemaThreadSafety.testThreadSafety() failures

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev reassigned SOLR-9983:
--

Assignee: Mikhail Khludnev

> TestManagedSchemaThreadSafety.testThreadSafety() failures
> -
>
> Key: SOLR-9983
> URL: https://issues.apache.org/jira/browse/SOLR-9983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: master (7.0)
>Reporter: Steve Rowe
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9983-connection-loss-retry.patch, SOLR-9983.patch, 
> tests-failures-TestManagedSchemaThreadSafety-724.txt
>
>
> I set up a Jenkins job to hammer all tests on the {{jira/solr-5944}} branch, 
> and at least four times this test failed (none of the seeds reproduce for 
> me): [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/155/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/167/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/106/], 
> [http://jenkins.sarowe.net/job/Solr-tests-SOLR-5944/332/].  My email search 
> didn't turn up any failures on ASF or Policeman Jenkins. Here's the output 
> from one of the above runs:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestManagedSchemaThreadSafety -Dtests.method=testThreadSafety 
> -Dtests.seed=3DB2B79301AA806B -Dtests.slow=true -Dtests.locale=lt 
> -Dtests.timezone=Asia/Anadyr -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   4.37s J4  | 
> TestManagedSchemaThreadSafety.testThreadSafety <<<
>[junit4]> Throwable #1: java.util.concurrent.ExecutionException: 
> java.lang.RuntimeException: org.apache.solr.common.SolrException: Error 
> loading solr config from solrconfig.xml
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([3DB2B79301AA806B:A7F8A3CBD235329D]:0)
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.testThreadSafety(TestManagedSchemaThreadSafety.java:126)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.RuntimeException: 
> org.apache.solr.common.SolrException: Error loading solr config from 
> solrconfig.xml
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.lambda$indexSchemaLoader$0(TestManagedSchemaThreadSafety.java:159)
>[junit4]>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>[junit4]>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]> Caused by: org.apache.solr.common.SolrException: Error 
> loading solr config from solrconfig.xml
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:187)
>[junit4]>  at 
> org.apache.solr.schema.TestManagedSchemaThreadSafety.lambda$indexSchemaLoader$0(TestManagedSchemaThreadSafety.java:152)
>[junit4]>  ... 6 more
>[junit4]> Caused by: java.lang.NullPointerException
>[junit4]>  at 
> org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:99)
>[junit4]>  at 
> org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:361)
>[junit4]>  at org.apache.solr.core.Config.(Config.java:120)
>[junit4]>  at org.apache.solr.core.Config.(Config.java:90)
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.(SolrConfig.java:202)
>[junit4]>  at 
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:179)
>[junit4]>  ... 7 more
> {noformat}
> Looks to me like this is a test bug: the test mocks {{ZkController}}, but the 
> mock returns null for (the uninitialized {{cc}} returned by) 
> {{getCoreContainer()}}, which is called when the ZK session expires in 
> {{ZkSolrResourceLoader.openResource()}}.  The NPE is triggered when 
> {{isShutdown()}} is called on the null core container:
> {code:java|title=ZkSolrResourceLoader.java}
>  97: } catch (KeeperException.SessionExpiredException e) {
>  98:   exception = e;
>  99:   if (!zkController.getCoreContainer().isShutDown()) {
> 100: // Retry 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+153) - Build # 2715 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2715/
Java: 64bit/jdk-9-ea+153 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestDetails

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([1F4B5D4C4468396C:65167E39D23010E4]:0)
at 
org.apache.solr.handler.TestReplicationHandler.doTestDetails(TestReplicationHandler.java:314)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 10981 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_1F4B5D4C4468396C-001/init-core-data-001
   [junit4]   2> 124073 INFO  
(SUITE-TestReplicationHandler-seed#[1F4B5D4C4468396C]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1219 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1219/

13 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([D81CD22ACA6A8BE4:7AC49CF0AE98A2E2]:0)
at 
org.apache.lucene.util.packed.Packed8ThreeBlocks.(Packed8ThreeBlocks.java:41)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:963)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:939)
at 
org.apache.lucene.util.packed.GrowableWriter.ensureCapacity(GrowableWriter.java:80)
at 
org.apache.lucene.util.packed.GrowableWriter.set(GrowableWriter.java:88)
at 
org.apache.lucene.util.packed.AbstractPagedMutable.set(AbstractPagedMutable.java:98)
at org.apache.lucene.util.fst.NodeHash.addNew(NodeHash.java:152)
at org.apache.lucene.util.fst.NodeHash.rehash(NodeHash.java:169)
at org.apache.lucene.util.fst.NodeHash.add(NodeHash.java:133)
at org.apache.lucene.util.fst.Builder.compileNode(Builder.java:200)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:296)
at org.apache.lucene.util.fst.Builder.add(Builder.java:400)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.writeFST(MemoryDocValuesConsumer.java:373)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:416)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:406)
at 
org.apache.lucene.codecs.DocValuesConsumer.mergeSortedField(DocValuesConsumer.java:527)
at 
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:139)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:151)
at 
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:167)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:111)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4322)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3899)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2075)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4945)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4983)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4974)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1582)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1324)
at 
org.apache.lucene.index.TestIndexSorting.testRandom3(TestIndexSorting.java:2299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


FAILED:  org.apache.solr.cloud.hdfs.HdfsChaosMonkeyNothingIsSafeTest.test

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([EF21E604632FDBF:86A621BAE8CE9047]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:850)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 

[jira] [Commented] (SOLR-9922) Write buffering updates to another tlog

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833624#comment-15833624
 ] 

Mark Miller commented on SOLR-9922:
---

This looks pretty good to me. I do see testDropBuffered in TestRecovery 
failing, but I had to add a little fuzz to apply the patch to UpdateLog, so I 
don't know if that caused some problem or if it was a later commit or it's a 
real issue with the patch.

Some nit pick notes:

TestRecovery:702  - we should look into this closely - is there any good use 
cases we currently count on that tests wouldn't catch for example?
// The updates that were buffered (but never applied) still appear in recent 
versions!
// This is good for some uses, but may not be good for others.

UpdateLog:959
Maybe add a comment why ensureLog calls deleteOldBufferLog

TestRecovery:752 bad javadoc - returns exception

HdfsUpdateLog - unused imports

RecoveryStrategy:289 - comment still talks about gap field

HdfsUpdateLog has commented out dropBufferedUpdates method we should remove as 
well

TransactionLog:154 source code formatting

> Write buffering updates to another tlog
> ---
>
> Key: SOLR-9922
> URL: https://issues.apache.org/jira/browse/SOLR-9922
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9922.patch, SOLR-9922.patch, SOLR-9922.patch
>
>
> Currently, we write buffering logs to current tlog and not apply that updates 
> to index. Then we rely on replay log to apply that updates to index. But at 
> the same time there are some updates also write to current tlog and applied 
> to the index. 
> For example, during peersync, if new updates come to replica we will end up 
> with this tlog
> tlog : old1, new1, new2, old2, new3, old3
> old updates belong to peersync, and these updates are applied to the index.
> new updates belong to buffering updates, and these updates are not applied to 
> the index.
> But writing all the updates to same current tlog make code base very complex. 
> We should write buffering updates to another tlog file.
> By doing this, it will help our code base simpler. It also makes replica 
> recovery for SOLR-9835 more easier. Because after peersync success we can 
> copy new updates from temporary file to current tlog, for example
> tlog : old1, old2, old3
> temporary tlog : new1, new2, new3
> -->
> tlog : old1, old2, old3, new1, new2, new3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-7651.
---
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)
   6.x

Fixed for now, please reopen for every bugfix release on any branch that was 
not yet updated to use this.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833620#comment-15833620
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I committed this to master and branch_5x. I will now disable all 6.4 branch 
builds. If we will have a further bugfix release on this branch, we should 
backport this. Please reopen in that case.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833619#comment-15833619
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit b808ee6099d03d1fdbccd5a17720069d74d0b8a4 in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b808ee6 ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833617#comment-15833617
 ] 

ASF subversion and git services commented on LUCENE-7651:
-

Commit ee5a36011220bd2a7a8e45de27d5321cc7610bff in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee5a360 ]

LUCENE-7651: Fix Javadocs build for Java 8u121 by injecting "Google Code 
Prettify" without adding Javascript to Javadocs's -bottom parameter. Also 
update Prettify to latest version to fix Google Chrome issue.


> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833574#comment-15833574
 ] 

Ishan Chattopadhyaya edited comment on SOLR-5944 at 1/22/17 4:24 PM:
-

Hoss did some initial single threaded benchmarks on the performance impact of 
doing in-place updates as compared to regular atomic updates.
{code}
The script [0] adds 20K docs containing a stored+indexed text field, a DVO long 
field, and a stored+indexed long field. It then does 50 iterations of 5K 
updates to each of the 2 long fields (500K updates total, 250K on the DVO 
field, 250K on the stored+indexed field), recording the cumulative total times 
for the udpates to each type of field.
{code}

Here are some results (times are in seconds):
Hoss' run, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|52|531|543|
|5944|51|352|503|

My run, as of right now:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|40|682|663|
|5944|36|295|694|

Seems like Hoss observed a 30% speedup on 5944 branch (in-place update vs. 
regular update), and I observed a 57% speedup on the same usecase. More 
benchmarks need to done to analyse the performance in multi-threaded indexing, 
and also to ensure there's no performance regression for non-dv updates.

 [0] - https://gist.github.com/anonymous/ae8bf7db3c713bf9d45937ec0aa1cfae


was (Author: ichattopadhyaya):
Hoss did some initial single threaded benchmarks on the performance impact of 
doing in-place updates as compared to regular atomic updates.
{code}
The script [0] adds 20K docs containing a stored+indexed text field, a DVO long 
field, and a stored+indexed text field. It then does 50 iterations of 5K 
updates to each of the 2 long fields (500K updates total, 250K on the DVO 
field, 250K on the stored+indexed field), recording the cumulative total times 
for the udpates to each type of field.
{code}

Here are some results (times are in seconds):
Hoss' run, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|52|531|543|
|5944|51|352|503|

My run, as of right now:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|40|682|663|
|5944|36|295|694|

Seems like Hoss observed a 30% speedup on 5944 branch (in-place update vs. 
regular update), and I observed a 57% speedup on the same usecase. More 
benchmarks need to done to analyse the performance in multi-threaded indexing, 
and also to ensure there's no performance regression for non-dv updates.

 [0] - https://gist.github.com/anonymous/ae8bf7db3c713bf9d45937ec0aa1cfae

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833574#comment-15833574
 ] 

Ishan Chattopadhyaya commented on SOLR-5944:


Hoss did some initial single threaded benchmarks on the performance impact of 
doing in-place updates as compared to regular atomic updates.
{code}
The script [0] adds 20K docs containing a stored+indexed text field, a DVO long 
field, and a stored+indexed text field. It then does 50 iterations of 5K 
updates to each of the 2 long fields (500K updates total, 250K on the DVO 
field, 250K on the stored+indexed field), recording the cumulative total times 
for the udpates to each type of field.
{code}

Here are some results (times are in seconds):
Hoss' run, as of c21d8a005387eae4d0f0adde4de7e4e465fb73c8, on his laptop:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|52|531|543|
|5944|51|352|503|

My run, as of right now:
||Branch||Adds||DVO Updates||stored+indexed Updates||
|master|40|682|663|
|5944|36|295|694|

Seems like Hoss observed a 30% speedup on 5944 branch (in-place update vs. 
regular update), and I observed a 57% speedup on the same usecase. More 
benchmarks need to done to analyse the performance in multi-threaded indexing, 
and also to ensure there's no performance regression for non-dv updates.

 [0] - https://gist.github.com/anonymous/ae8bf7db3c713bf9d45937ec0aa1cfae

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
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-6.4-Windows (64bit/jdk1.8.0_121) - Build # 7 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Windows/7/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 55644 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.standard...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.blocktree...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene60...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene62...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.geo...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.bkd...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.graph...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] 1 error

[...truncated 2 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\build.xml:775: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\build.xml:101: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\lucene\build.xml:138: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\lucene\common-build.xml:746: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\lucene\core\build.xml:54: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\lucene\common-build.xml:2100:
 Javadoc returned 1

Total time: 89 minutes 25 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-6.4 - Build # 8 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/8/

5 tests failed.
FAILED:  org.apache.lucene.search.TestFuzzyQuery.testRandom

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([490F89363696DA3]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.search.TestFuzzyQuery

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([490F89363696DA3]:0)


FAILED:  
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Expected to see collection awhollynewcollection_0 null Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/8)={
   "replicationFactor":"2",   "shards":{ "shard1":{   
"range":"8000-bfff",   "state":"active",   "replicas":{}}, 
"shard2":{   "range":"c000-",   "state":"active",   
"replicas":{}}, "shard3":{   "range":"0-3fff",   
"state":"active",   "replicas":{}}, "shard4":{   
"range":"4000-7fff",   "state":"active",   "replicas":{}}},   
"router":{"name":"compositeId"},   "maxShardsPerNode":"3",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected to see collection awhollynewcollection_0
null
Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/8)={
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-bfff",
  "state":"active",
  "replicas":{}},
"shard2":{
  "range":"c000-",
  "state":"active",
  "replicas":{}},
"shard3":{
  "range":"0-3fff",
  "state":"active",
  "replicas":{}},
"shard4":{
  "range":"4000-7fff",
  "state":"active",
  "replicas":{}}},
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"3",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([1381836DAD0C4BD6:5BF4F7D9AB3F6443]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:496)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[JENKINS] Lucene-Solr-6.4-Linux (64bit/jdk1.8.0_121) - Build # 46 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/46/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplicaProp

Error Message:
Error from server at https://127.0.0.1:32803/solr: Could not fully create 
collection: replicaProperties

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:32803/solr: Could not fully create collection: 
replicaProperties
at 
__randomizedtesting.SeedInfo.seed([94CDA59050B745BC:50161A78EB98B6D0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplicaProp(CollectionsAPISolrJTest.java:309)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 627 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/627/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 55616 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.standard...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.blocktree...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene60...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene62...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.geo...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.bkd...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.graph...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] 1 error

[...truncated 2 lines...]
BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:775: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/build.xml:138: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:746:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/core/build.xml:54:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2100:
 Javadoc returned 1

Total time: 94 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1090 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1090/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.PeerSyncReplicationTest.test

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([9070C66A508CF174:1824F9B0FE709C8C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833484#comment-15833484
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I sent the following message to OpenJDK: 
http://mail.openjdk.java.net/pipermail/javadoc-dev/2017-January/000281.html

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833480#comment-15833480
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I just checked. The "hack" also works with IBM J9, so I see no problem doing 
this. I was afraid that maybe IBM does not have script.js in the Javadoc output.

Nevertheless, this is not risky like the previous hack. If the Javadocs 
generator no longer produces script.js or stylesheet.css the Code Prettify 
would just no longer work, but not break Javadocs or build.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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: HitQueue.getSentinelObject() and performance

[Michael McCandless]

Aha!  Thanks for bringing closure...

Mike McCandless

http://blog.mikemccandless.com

On Sat, Jan 21, 2017 at 4:24 PM, Rob Audenaerde
 wrote:
> Hi Mike,
>
> I was curious too, so with the help of your hint I did some more digging.
> You were correct, as I found two occurences using this construction:
>
> final TopDocs topDocs = indexSearcher.search(pageQuery,
> Integer.MAX_VALUE);
>
> As there are 4.5M documents in this specific index, this caused many calls.
>
> Thanks!
>
> -Rob
>
>
>
> On Fri, Jan 20, 2017 at 5:23 PM, Michael McCandless
>  wrote:
>>
>> It's curious that you see this as a hot spot.
>>
>> Are you collecting a very large top N docs, relative to how many hits
>> the queries match, maybe?
>>
>> I don't think we can make this a static instance: the collection
>> process will re-use the entry it pulls out of the queue.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Fri, Jan 20, 2017 at 10:39 AM, Rob Audenaerde
>>  wrote:
>> > Hi all,
>> >
>> > I'm currently looking at the performance of our application, and I see a
>> > lot
>> > of time being spent in  HitQueue.getSentinelObject()   (I track this
>> > using
>> > the VisualVM sampler)
>> >
>> > When I look at the implementation, I see a new ScoreDoc is constructed
>> > each
>> > time. Is this necessary? Maybe a static will improve the performance a
>> > bit?
>> >
>> >
>> > @Override
>> >   protected ScoreDoc getSentinelObject() {
>> > // Always set the doc Id to MAX_VALUE so that it won't be favored by
>> > // lessThan. This generally should not happen since if score is not
>> > NEG_INF,
>> > // TopScoreDocCollector will always add the object to the queue.
>> > return new ScoreDoc(Integer.MAX_VALUE, Float.NEGATIVE_INFINITY);
>> >   }
>> >
>> > Thanks in advance,
>> > - Rob
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 655 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/655/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 55620 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.standard...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.blocktree...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene60...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene62...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.geo...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.bkd...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.graph...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
  [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
  [javadoc] 1 error

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:775: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:138: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:746: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/core/build.xml:54: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2100: 
Javadoc returned 1

Total time: 92 minutes 23 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Add correct license header to CSS file.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-6.4-Linux (32bit/jdk1.8.0_121) - Build # 45 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/45/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=4633, name=jetty-launcher-768-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=4637, name=jetty-launcher-768-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=4633, name=jetty-launcher-768-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Updated] (SOLR-10022) solr fieldType change failed

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

王海涛 updated SOLR-10022:
---
Attachment: step5.png
step4 .png
step3.png
step2.png
step1.png
step6.png

> solr fieldType  change failed
> -
>
> Key: SOLR-10022
> URL: https://issues.apache.org/jira/browse/SOLR-10022
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.2.1
> Environment: solrCloud/solr one node
>Reporter: 王海涛
> Attachments: step1.png, step2.png, step3.png, step4 .png, step5.png, 
> step6.png
>
>
> After change schema fieldType , solr index full import failed.
> I must restart my solr ,then solr index full import OK.
> more info about this bug ,please see attaches



--
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-10022) solr fieldType change failed

[JIRA]

王海涛 created SOLR-10022:
--

 Summary: solr fieldType  change failed
 Key: SOLR-10022
 URL: https://issues.apache.org/jira/browse/SOLR-10022
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: 6.2.1
 Environment: solrCloud/solr one node
Reporter: 王海涛


After change schema fieldType , solr index full import failed.
I must restart my solr ,then solr index full import OK.

more info about this bug ,please see attaches



--
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-10022) solr fieldType change failed

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833453#comment-15833453
 ] 

王海涛 commented on SOLR-10022:


rg.apache.solr.common.SolrException: Exception writing document id 475783 to 
the index; possible analysis error: cannot change DocValues type from SORTED to 
NUMERIC for field "xf_propotype_id"
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:171)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:939)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1094)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:720)
at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at 
org.apache.solr.handler.dataimport.SolrWriter.upload(SolrWriter.java:74)
at 
org.apache.solr.handler.dataimport.DataImportHandler$1.upload(DataImportHandler.java:254)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:524)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:475)
at 
org.apache.solr.handler.dataimport.DataImporter.lambda$runAsync$0(DataImporter.java:458)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: cannot change DocValues type 
from SORTED to NUMERIC for field "esf_has_subways"
at 
org.apache.lucene.index.FieldInfos$FieldNumbers.verifyConsistent(FieldInfos.java:291)
at 
org.apache.lucene.index.FieldInfos$FieldNumbers.setDocValuesType(FieldInfos.java:335)
at 
org.apache.lucene.index.DefaultIndexingChain.indexDocValue(DefaultIndexingChain.java:507)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:449)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:373)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:231)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:478)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1562)
at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:279)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:211)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:166)
... 16 more
Last Check: 2017/1/22 上午11:17:41

> solr fieldType  change failed
> -
>
> Key: SOLR-10022
> URL: https://issues.apache.org/jira/browse/SOLR-10022
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.2.1
> Environment: solrCloud/solr one node
>Reporter: 王海涛
>
> After change schema fieldType , solr index full import failed.
> I must restart my solr ,then solr index full import OK.
> more info about this bug ,please see attaches



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Final updates, I think this is committable.

Any suggestions?

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Attached is a patch that also updates Prettify to latest version. The used one 
produced Javascript errors in Chrome, so I updated. I also removed the useless 
additional language plugin files.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-10008) Move the reference to CoreContainer from CoreDescriptor to SolrCore.

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833431#comment-15833431
 ] 

Alan Woodward commented on SOLR-10008:
--

+1, I started to have a go at this a couple of years ago.  You can remove 
CoreContainer from a couple more CD constructors as well, I think?

> Move the reference to CoreContainer from CoreDescriptor to SolrCore.
> 
>
> Key: SOLR-10008
> URL: https://issues.apache.org/jira/browse/SOLR-10008
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: trunk, 6.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10008.patch
>
>
> CoreDescriptor referencing CoreContainer is just weird. If anyplace, the 
> SolrCore should have a reference to CoreContainer.



--
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-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2712 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2712/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 53877 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1810703121
 [ecj-lint] Compiling 810 source files to /tmp/ecj1810703121
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/core/src/java/org/apache/lucene/document/SortedSetDocValuesRangeQuery.java
 (at line 22)
 [ecj-lint] import org.apache.lucene.index.DocValues;
 [ecj-lint]^
 [ecj-lint] The import org.apache.lucene.index.DocValues is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java
 (at line 4308)
 [ecj-lint] newReader = new SegmentReader(info, reader, liveDocs, 
info.info.maxDoc() - delCount);
 [ecj-lint] 

 [ecj-lint] Resource leak: 'newReader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/core/src/java/org/apache/lucene/index/SegmentReader.java
 (at line 159)
 [ecj-lint] return null;
 [ecj-lint] 
 [ecj-lint] Resource leak: 'dir' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3 problems (1 error, 2 warnings)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:101: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:199: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:1992: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2031: 
Compile failed; see the compiler error output for details.

Total time: 65 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833424#comment-15833424
 ] 

Uwe Schindler edited comment on LUCENE-7651 at 1/22/17 9:50 AM:


This would be my proposal.


was (Author: thetaphi):
This would be my proposal. Unfortunately, Prettify never worked from local 
filesystem, so I have to quicly spawn a webserver here...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3789 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3789/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 55492 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.standard...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.blocktree...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene60...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene62...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene70...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.geo...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.bkd...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.graph...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
  [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
  [javadoc] 1 error

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:775: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:138: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:746: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/core/build.xml:54: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2101:
 Javadoc returned 1

Total time: 94 minutes 26 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: (was: LUCENE-7651.patch)

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

Sorry last patch had a missing pair of brackets. This fixes it any also works 
locally. Stupid Javascript! K!

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Attachment: LUCENE-7651.patch

This would be my proposal. Unfortunately, Prettify never worked from local 
filesystem, so I have to quicly spawn a webserver here...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Attachments: LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-SmokeRelease-master - Build # 681 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/681/

No tests ran.

Build Log:
[...truncated 41971 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 30.5 MB in 0.03 sec (1133.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 65.1 MB in 0.06 sec (1152.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 76.1 MB in 0.07 sec (1140.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6204 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6204 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   6.4.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1474, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1418, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1456, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, gitRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 768, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:571:
 exec returned: 1

Total time: 39 minutes 50 seconds
Build step 'Invoke Ant' marked build as failure
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833417#comment-15833417
 ] 

Uwe Schindler commented on LUCENE-7651:
---

This implements first option:

{noformat}
 lucene/common-build.xml | 14 --
 1 file changed, 14 deletions(-)

diff --git a/lucene/common-build.xml b/lucene/common-build.xml
index 48cf457..61948bb 100644
--- a/lucene/common-build.xml
+++ b/lucene/common-build.xml
@@ -2107,20 +2107,6 @@ 
${ant.project.name}.test.dependencies=${test.classpath.list}
 
 
 
 
{noformat}

I checked our sources. We allready append the CSS of prettify to Javadocs's 
main CSS files. As Java 8 contains also a Javadocs-generated scripts.js file, 
we could do the same here. I am working on that...

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833412#comment-15833412
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I checked it out, it disallows any 

[jira] [Updated] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Labels: Java8  (was: )

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7651:
--
Affects Version/s: 6.4

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned LUCENE-7651:
-

Assignee: Uwe Schindler

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833398#comment-15833398
 ] 

Uwe Schindler edited comment on LUCENE-7651 at 1/22/17 9:19 AM:


I set to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.


was (Author: thetaphi):
I se to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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: [JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6363 - Failure!

[Uwe Schindler]

Hi,

 

See https://issues.apache.org/jira/browse/LUCENE-7651

If you update your local JDK to Oracle’s recent Java 8 update 121, it breaks.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Alan Woodward [mailto:a...@flax.co.uk] 
Sent: Sunday, January 22, 2017 10:09 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build 
# 6363 - Failure!

 

Anyone know what’s going on here?  Running ant javadocs on master locally 
passes with no problems.

 

Alan Woodward
www.flax.co.uk  

 

On 22 Jan 2017, at 06:39, Policeman Jenkins Server  > wrote:

 

 [javadoc] Constructing Javadoc information...
 [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
 [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
 [javadoc] 1 error

 

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833399#comment-15833399
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I will try to figure out if moving the Javascript to a separate file helps 
here. In HTML 5 inline Javascript in HTML files is a no-go.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
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-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833398#comment-15833398
 ] 

Uwe Schindler commented on LUCENE-7651:
---

I se to "critical", because this also breaks our latest release 6.4, which 
can't be build from source with Java 8 update 121.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Priority: Critical
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7651) Javadocs build fails with Java 8 update 121

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-7651:
-

 Summary: Javadocs build fails with Java 8 update 121
 Key: LUCENE-7651
 URL: https://issues.apache.org/jira/browse/LUCENE-7651
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/javadocs
 Environment: Java 8 update 121
Reporter: Uwe Schindler
Priority: Critical


Oracle released the recent Java 8 security update (u121). The Jenkins builds 
fail with the following error while building the Javadocs:

{noformat}
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
  [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
  [javadoc] 1 error
{noformat}

This is caused by the Javascript added to pretty-print code examples. We load 
this in the page footer "{{}}" parameter.

Surely, it will be posisble to simply add the mentioned argument, but this will 
break builds with earlier Java 8 versions.

This is nowhere documented, I haven't seen any documentation about this flag 
nowhere, so I assume this is a bug in Java. They can't change or add command 
line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
lists if this is a bug (maybe accidentally backported from Java 9).



--
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: [JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6363 - Failure!

[Alan Woodward]

Anyone know what’s going on here?  Running ant javadocs on master locally 
passes with no problems.

Alan Woodward
www.flax.co.uk


> On 22 Jan 2017, at 06:39, Policeman Jenkins Server  
> wrote:
> 
>  [javadoc] Constructing Javadoc information...
>  [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>  [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>  [javadoc] 1 error

[jira] [Resolved] (SOLR-3965) CoreAdminHandler does not do "property expansion" on values wren creating new core

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward resolved SOLR-3965.
-
   Resolution: Duplicate
 Assignee: Erick Erickson
Fix Version/s: 4.4

This was fixed by SOLR-4982, back in 2013.

> CoreAdminHandler does not do "property expansion" on values wren creating new 
> core
> --
>
> Key: SOLR-3965
> URL: https://issues.apache.org/jira/browse/SOLR-3965
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Sami Siren
>Assignee: Erick Erickson
> Fix For: 4.4
>
>
> Let's say I have a core definition in my solr.xml like this:
> {code}
>  dataDir="${DataHome}/cores/core/data"/>
> {code}
> When I want to add more cores through the coreAdminHandler so that the data 
> goes under the same base dir I cannot use ${DataHome} but I have to use a 
> absolute directory instead. 
> Using property references stores everything correctly in solr.xml but the 
> actual value used for the data dir of the new core is incorrect (until solr 
> is restarted).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+153) - Build # 18820 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18820/
Java: 64bit/jdk-9-ea+153 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.lucene.util.bkd.TestBKD.testEstimatePointCount

Error Message:
expected:<144> but was:<288>

Stack Trace:
java.lang.AssertionError: expected:<144> but was:<288>
at 
__randomizedtesting.SeedInfo.seed([C47CE5220A24BF8C:B424AE50A9F01CE5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.lucene.util.bkd.TestBKD.testEstimatePointCount(TestBKD.java:1176)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 632 lines...]
   [junit4] Suite: org.apache.lucene.util.bkd.TestBKD
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBKD 
-Dtests.method=testEstimatePointCount -Dtests.seed=C47CE5220A24BF8C 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sw-TZ 
-Dtests.timezone=Pacific/Majuro -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.07s J1 | TestBKD.testEstimatePointCount <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<144> 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_121) - Build # 697 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/697/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 53871 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: C:\Users\jenkins\AppData\Local\Temp\ecj1259682608
 [ecj-lint] Compiling 810 source files to 
C:\Users\jenkins\AppData\Local\Temp\ecj1259682608
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\core\src\java\org\apache\lucene\document\SortedSetDocValuesRangeQuery.java
 (at line 22)
 [ecj-lint] import org.apache.lucene.index.DocValues;
 [ecj-lint]^
 [ecj-lint] The import org.apache.lucene.index.DocValues is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\core\src\java\org\apache\lucene\index\IndexWriter.java
 (at line 4308)
 [ecj-lint] newReader = new SegmentReader(info, reader, liveDocs, 
info.info.maxDoc() - delCount);
 [ecj-lint] 

 [ecj-lint] Resource leak: 'newReader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\core\src\java\org\apache\lucene\index\SegmentReader.java
 (at line 159)
 [ecj-lint] return null;
 [ecj-lint] 
 [ecj-lint] Resource leak: 'dir' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3 problems (1 error, 2 warnings)

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:775: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:101: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build.xml:199: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:1992:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:2031:
 Compile failed; see the compiler error output for details.

Total time: 89 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org