date:20170110

[jira] [Resolved] (SOLR-9886) Add ability to turn off/on caches

2017-01-10 Thread Noble Paul (JIRA)


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

Noble Paul resolved SOLR-9886.
--
   Resolution: Fixed
Fix Version/s: 6.4
   master (7.0)

> Add ability to turn off/on caches 
> --
>
> Key: SOLR-9886
> URL: https://issues.apache.org/jira/browse/SOLR-9886
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: EnableDisableCacheAttribute.patch, SOLR-9886.patch, 
> SOLR-9886.patch
>
>
> There is no elegant way to turn off caches (filterCache, queryResultCache 
> etc) from the solrconfig. When I tried setting size and initialSize to zero, 
> it resulted in caches of size 2. Here is the code that overrides setting zero 
> sized cache. 
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/FastLRUCache.java#L61-L73
> Only way to disable cache right now is by removing cache configs from the 
> solrConfig, but we can simply provide an attribute to disable cache, so that 
> we can override it using a system property. 



--
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-9950) TestRecovery.testBuffering() failure

2017-01-10 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on SOLR-9950:
-

Thanks Steve for reporting this - manual testing on OSX didn't reproduce, I was 
only able to reproduce this with the following command:
{code}
ant test  -Dtestcase=TestRecovery -Dtests.seed=416C60950450F681 
-Dtests.slow=true -Dtests.locale=no -Dtests.timezone=America/Rainy_River 
-Dtests.asserts=true -Dtests.file.encodingTF-8 -Dtests.dups=4 -Dtests.iters=10
{code}
I committed a fix, let's see what jenkins says.

> TestRecovery.testBuffering() failure
> 
>
> Key: SOLR-9950
> URL: https://issues.apache.org/jira/browse/SOLR-9950
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.4
>
> Attachments: policeman-jenkins-master-windows-6347-failed-tests.log.gz
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6347], 
> reproduces 100% for me on Linux:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
> -Dtests.method=testBuffering -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=no -Dtests.timezone=America/Rainy_River -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.10s J1 | TestRecovery.testBuffering <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<6> but 
> was:<10>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:5C82CEBEA50957AA]:0)
>[junit4]>  at 
> org.apache.solr.search.TestRecovery.testBuffering(TestRecovery.java:284)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {_version_=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
>  val_i=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct)}, 
> docValues:{}, maxPointsInLeafNode=1974, maxMBSortInHeap=7.099504359147245, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=no, 
> timezone=America/Rainy_River
>[junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_112 
> (64-bit)/cpus=3,threads=1,free=213046664,total=411041792
> {noformat}
> Another test failure that on the same run doesn't reproduce for me, but these 
> two tests were running on the same JVM, and so may have somehow influenced 
> each other:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=RecoveryZkTest 
> -Dtests.method=test -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=da -Dtests.timezone=EAT -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 12.2s J1 | RecoveryZkTest.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Mismatch in counts 
> between replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:C9385F4FAAAC9B79]:0)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
> {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] [Updated] (SOLR-9950) TestRecovery.testBuffering() failure

2017-01-10 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  updated SOLR-9950:

Fix Version/s: 6.4
   master (7.0)

> TestRecovery.testBuffering() failure
> 
>
> Key: SOLR-9950
> URL: https://issues.apache.org/jira/browse/SOLR-9950
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.4
>
> Attachments: policeman-jenkins-master-windows-6347-failed-tests.log.gz
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6347], 
> reproduces 100% for me on Linux:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
> -Dtests.method=testBuffering -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=no -Dtests.timezone=America/Rainy_River -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.10s J1 | TestRecovery.testBuffering <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<6> but 
> was:<10>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:5C82CEBEA50957AA]:0)
>[junit4]>  at 
> org.apache.solr.search.TestRecovery.testBuffering(TestRecovery.java:284)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {_version_=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
>  val_i=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct)}, 
> docValues:{}, maxPointsInLeafNode=1974, maxMBSortInHeap=7.099504359147245, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=no, 
> timezone=America/Rainy_River
>[junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_112 
> (64-bit)/cpus=3,threads=1,free=213046664,total=411041792
> {noformat}
> Another test failure that on the same run doesn't reproduce for me, but these 
> two tests were running on the same JVM, and so may have somehow influenced 
> each other:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=RecoveryZkTest 
> -Dtests.method=test -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=da -Dtests.timezone=EAT -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 12.2s J1 | RecoveryZkTest.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Mismatch in counts 
> between replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:C9385F4FAAAC9B79]:0)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
> {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] [Assigned] (SOLR-9950) TestRecovery.testBuffering() failure

2017-01-10 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  reassigned SOLR-9950:
---

Assignee: Andrzej Bialecki 

> TestRecovery.testBuffering() failure
> 
>
> Key: SOLR-9950
> URL: https://issues.apache.org/jira/browse/SOLR-9950
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Attachments: policeman-jenkins-master-windows-6347-failed-tests.log.gz
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6347], 
> reproduces 100% for me on Linux:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
> -Dtests.method=testBuffering -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=no -Dtests.timezone=America/Rainy_River -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.10s J1 | TestRecovery.testBuffering <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<6> but 
> was:<10>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:5C82CEBEA50957AA]:0)
>[junit4]>  at 
> org.apache.solr.search.TestRecovery.testBuffering(TestRecovery.java:284)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {_version_=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
>  val_i=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct)}, 
> docValues:{}, maxPointsInLeafNode=1974, maxMBSortInHeap=7.099504359147245, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=no, 
> timezone=America/Rainy_River
>[junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_112 
> (64-bit)/cpus=3,threads=1,free=213046664,total=411041792
> {noformat}
> Another test failure that on the same run doesn't reproduce for me, but these 
> two tests were running on the same JVM, and so may have somehow influenced 
> each other:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=RecoveryZkTest 
> -Dtests.method=test -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=da -Dtests.timezone=EAT -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 12.2s J1 | RecoveryZkTest.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Mismatch in counts 
> between replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:C9385F4FAAAC9B79]:0)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
> {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] [Commented] (SOLR-9950) TestRecovery.testBuffering() failure

2017-01-10 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-9950:
---

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

SOLR-9950 Check the difference in counts - meter may not be zero at this point.


> TestRecovery.testBuffering() failure
> 
>
> Key: SOLR-9950
> URL: https://issues.apache.org/jira/browse/SOLR-9950
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: policeman-jenkins-master-windows-6347-failed-tests.log.gz
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6347], 
> reproduces 100% for me on Linux:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRecovery 
> -Dtests.method=testBuffering -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=no -Dtests.timezone=America/Rainy_River -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.10s J1 | TestRecovery.testBuffering <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<6> but 
> was:<10>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:5C82CEBEA50957AA]:0)
>[junit4]>  at 
> org.apache.solr.search.TestRecovery.testBuffering(TestRecovery.java:284)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {_version_=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
>  val_i=PostingsFormat(name=Direct), id=PostingsFormat(name=Direct)}, 
> docValues:{}, maxPointsInLeafNode=1974, maxMBSortInHeap=7.099504359147245, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=no, 
> timezone=America/Rainy_River
>[junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_112 
> (64-bit)/cpus=3,threads=1,free=213046664,total=411041792
> {noformat}
> Another test failure that on the same run doesn't reproduce for me, but these 
> two tests were running on the same JVM, and so may have somehow influenced 
> each other:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=RecoveryZkTest 
> -Dtests.method=test -Dtests.seed=416C60950450F681 -Dtests.slow=true 
> -Dtests.locale=da -Dtests.timezone=EAT -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 12.2s J1 | RecoveryZkTest.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Mismatch in counts 
> between replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([416C60950450F681:C9385F4FAAAC9B79]:0)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
>[junit4]>  at 
> org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
> {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

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

2017-01-10 Thread Policeman Jenkins Server

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

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1733, name=SocketProxy-Response-62434:62720, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([834455F2095F62BD:B106A28A7A30F45]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([834455F2095F62BD]: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 10858 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.HttpPartitionTest_834455F2095F62BD-001\init-core-data-001
   [junit4]   2> 195671 INFO  
(SUITE-HttpPartitionTest-seed#[834455F2095F62BD]-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> 195671 INFO  
(SUITE-HttpPartitionTest-seed#[834455F2095F62BD]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 195675 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 195678 INFO  (Thread-286) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 195678 INFO  (Thread-286) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 195777 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.ZkTestServer start zk server on port:62394
   [junit4]   2> 195811 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 195815 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 195818 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 195820 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 195822 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 195825 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 195828 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 195831 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 195833 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\mapping-ISOLatin1Accent.txt
 to /configs/conf1/mapping-ISOLatin1Accent.txt
   [junit4]   2> 195836 INFO  
(TEST-HttpPartitionTest.test-seed#[834455F2095F62BD]) [] 
o.a.s.c.AbstractZkTestCase put

[jira] [Commented] (SOLR-9886) Add ability to turn off/on caches

2017-01-10 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-9886:
---

Commit 39502a09eecbb52bf26bd52a4104ba59bca3900b in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39502a0 ]

* SOLR-9886: Add a 'enable' flag to caches to enable/disable them


> Add ability to turn off/on caches 
> --
>
> Key: SOLR-9886
> URL: https://issues.apache.org/jira/browse/SOLR-9886
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: EnableDisableCacheAttribute.patch, SOLR-9886.patch, 
> SOLR-9886.patch
>
>
> There is no elegant way to turn off caches (filterCache, queryResultCache 
> etc) from the solrconfig. When I tried setting size and initialSize to zero, 
> it resulted in caches of size 2. Here is the code that overrides setting zero 
> sized cache. 
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/FastLRUCache.java#L61-L73
> Only way to disable cache right now is by removing cache configs from the 
> solrConfig, but we can simply provide an attribute to disable cache, so that 
> we can override it using a system property. 



--
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-9886) Add ability to turn off/on caches

2017-01-10 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-9886:
--

It should be OK

> Add ability to turn off/on caches 
> --
>
> Key: SOLR-9886
> URL: https://issues.apache.org/jira/browse/SOLR-9886
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: EnableDisableCacheAttribute.patch, SOLR-9886.patch, 
> SOLR-9886.patch
>
>
> There is no elegant way to turn off caches (filterCache, queryResultCache 
> etc) from the solrconfig. When I tried setting size and initialSize to zero, 
> it resulted in caches of size 2. Here is the code that overrides setting zero 
> sized cache. 
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/FastLRUCache.java#L61-L73
> Only way to disable cache right now is by removing cache configs from the 
> solrConfig, but we can simply provide an attribute to disable cache, so that 
> we can override it using a system property. 



--
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-9886) Add ability to turn off/on caches

2017-01-10 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-9886:
---

Commit 2048b82443db548f76d584f9a95b5628c407edde in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2048b82 ]

* SOLR-9886: Add a 'enable' flag to caches to enable/disable them


> Add ability to turn off/on caches 
> --
>
> Key: SOLR-9886
> URL: https://issues.apache.org/jira/browse/SOLR-9886
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: EnableDisableCacheAttribute.patch, SOLR-9886.patch, 
> SOLR-9886.patch
>
>
> There is no elegant way to turn off caches (filterCache, queryResultCache 
> etc) from the solrconfig. When I tried setting size and initialSize to zero, 
> it resulted in caches of size 2. Here is the code that overrides setting zero 
> sized cache. 
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/FastLRUCache.java#L61-L73
> Only way to disable cache right now is by removing cache configs from the 
> solrConfig, but we can simply provide an attribute to disable cache, so that 
> we can override it using a system property. 



--
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-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work

2017-01-10 Thread JIRA


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

Jan Høydahl commented on SOLR-9584:
---

I think I agree more with this change. Proxying Solr behind nginx or something 
should be possible even if the path is different from /solr/.

Have you tested your patch? Have you checked whether other parts of Admin UI 
also has hardcoded /solr/ paths?

> The absolute URL path in server/solr-webapp/webapp/js/angular/services.js 
> would make context customization not work
> ---
>
> Key: SOLR-9584
> URL: https://issues.apache.org/jira/browse/SOLR-9584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.2
>Reporter: Yun Jie Zhou
>Priority: Minor
>  Labels: patch
>
> The absolute path starting from /solr in 
> server/solr-webapp/webapp/js/angular/services.js would make the context 
> customization not work.
> For example, we should use $resource('admin/info/system', {"wt":"json", 
> "_":Date.now()}); instead of $resource('/solr/admin/info/system', 
> {"wt":"json", "_":Date.now()});



--
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-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work

2017-01-10 Thread JIRA


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

Jan Høydahl updated SOLR-9584:
--
Component/s: (was: Server)
 UI

> The absolute URL path in server/solr-webapp/webapp/js/angular/services.js 
> would make context customization not work
> ---
>
> Key: SOLR-9584
> URL: https://issues.apache.org/jira/browse/SOLR-9584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.2
>Reporter: Yun Jie Zhou
>Priority: Minor
>  Labels: patch
>
> The absolute path starting from /solr in 
> server/solr-webapp/webapp/js/angular/services.js would make the context 
> customization not work.
> For example, we should use $resource('admin/info/system', {"wt":"json", 
> "_":Date.now()}); instead of $resource('/solr/admin/info/system', 
> {"wt":"json", "_":Date.now()});



--
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

JDK 9 EA Build 151 is available on java.net

2017-01-10 Thread Rory O'Donnell



Hi Uwe & Dawid,

Best wishes for the New Year.

Dalibor and I will be at FOSDEM '17, Brussels 4 & 5 February. Let us 
know if you will be there, hopefully we can meet up !


*JDK 9 Early Access* b151   is 
available on java.net


Can you confirm fixes for

1. JDK-8171377 : Add sun.misc.Unsafe::invokeCleaner
2. JDK-8075793 : Source incompatibility for inference using -source 7


There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :


 * JDK-8087303 : LSSerializer pretty print does not work anymore
 * JDK-8167143 :CLDR timezone parsing does not work for all locales

Other changes that maybe of interest:

 * JDK-8066474 : Remove the lib/$ARCH directory from Linux and Solaris
   images
 * JDK-8170428 : Move src.zip to JDK/lib/src.zip

*JEPs intergrated:*

 * JEP 295 : Ahead-of-Time
   Compilation has been integrated in b150.

*Schedule - Milestones since last availability email *

 * *Feature Extension Complete 22nd of December 2016*
 * *Rampdown Started 5th of January 2017
   *
 o Phases in which increasing levels of scrutiny are applied to
   incoming changes.
 o In phase 1, only P1-P3 bugs can be fixed. In phase 2 only
   showstopper bugs can be fixed.

Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Commented] (SOLR-9941) log replay redundently (pre-)applies DBQs as if they were out of order

2017-01-10 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-9941:


+1 for remove {{boolean onStartup}}. 
The rest a good to me.

> log replay redundently (pre-)applies DBQs as if they were out of order
> --
>
> Key: SOLR-9941
> URL: https://issues.apache.org/jira/browse/SOLR-9941
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9941.hoss-test-experiment.patch, SOLR-9941.patch, 
> SOLR-9941.patch, SOLR-9941.patch
>
>
> There's kind of an odd situation that arises when a Solr node starts up 
> (after a crash) and tries to recover from it's tlog that causes deletes to be 
> redundantly & excessively applied -- at a minimum it causes confusing really 
> log messages
> * {{UpdateLog.init(...)}} creates {{TransactionLog}} instances for the most 
> recent log files found (based on numRecordsToKeep) and then builds a 
> {{RecentUpdates}} instance from them
> * Delete entries from the {{RecentUpdates}} are used to populate 2 lists:
> ** {{deleteByQueries}}
> ** {{oldDeletes}} (for deleteById).
> * Then when {{UpdateLog.recoverFromLog}} is called a {{LogReplayer}} is used 
> to replay any (uncommited) {{TransactionLog}} enteries
> ** during replay {{UpdateLog}} delegates to the UpdateRequestProcessorChain 
> to for the various adds/deletes, etc...
> ** when an add makes it to {{RunUpdateProcessor}} it delegates to 
> {{DirectUpdateHandler2}}, which (independent of the fact that we're in log 
> replay) calls {{UpdateLog.getDBQNewer}} for every add, looking for any 
> "Reordered" deletes that have a version greater then the add
> *** if it finds _any_ DBQs "newer" then the document being added, it does a 
> low level {{IndexWriter.updateDocument}} and then immediately executes _all_ 
> the newer DBQs ... _once per add_
> ** these deletes are *also* still executed as part of the normal tlog replay, 
> because they are in the tlog.
> Which means if you are recovering from a tlog with 90 addDocs, followed by 5 
> DBQs, then *each* of those 5 DBQs will each be executed 91 times -- and for 
> 90 of those executions, a DUH2 INFO log messages will say {{"Reordered DBQs 
> detected. ..."}} even tough the only reason they are out of order is because 
> Solr is deliberately applying them out of order.
> * At a minimum we should improve the log messages
> * Ideally we should stop (pre-emptively) applying these deletes during tlog 
> replay.



--
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-9000) New Admin UI hardcodes /solr context and fails when it changes

2017-01-10 Thread Timo Hund (JIRA)


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

Timo Hund commented on SOLR-9000:
-

I know that the port can be used. And i also undestand an agree that solr 
should be a blackbox which means that internally in the java application the 
assumption is made that /solr is the path. What do you think about SOLR-9584? I 
think this is something different because it is related to the use interface, a 
proxy would not have a chance to change the delivered javascript code.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
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-9941) log replay redundently (pre-)applies DBQs as if they were out of order

2017-01-10 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat edited comment on SOLR-9941 at 1/10/17 9:17 AM:
-

Here are the reason to explain why Hoss's test fails :
- When the test add updates, it will be written to tlog-
- After the core is restarted, it will replay the updates from tlog-
- In the same time, the test add another DEQ, because the ulog is not active, 
DUP will write this DEQ to another file ( tlog-0001, buffering updates) and 
ignore apply this DEQ to IW.
{code:title=DistributedUpdateProcess.java|borderStyle=solid}
// we're not in an active state, and this update isn't from a replay, so buffer 
it.
cmd.setFlags(cmd.getFlags() | UpdateCommand.BUFFERING);
ulog.add(cmd);
{code}
- After LogReplay finish, we call a commit, which will write a commit update at 
the end of tlog-0001

So this DEQ update will never be replayed ( because it belong tlog-0001 not 
tlog- ), and it've never been applied to IW, so that DEQ update is lost.

But this do not mean we have a problem with SolrCloud mode or single instance 
mode. 
In SolrCloud mode, when a replica run recoverFromLog, replica in this time 
period will have state = DOWN, so It won't receive any updates.

In single instance mode, we will run in leader logic, so the DEQ is applied to 
IW immediately ( along with update {{ulog.deleteByQueries}} ).

In TestRecovery, we kinda mixed up single instance code path along with 
SolrCloud mode code path, so we end up with the fail.


was (Author: caomanhdat):
Here are the reason to explain why Hoss's test fails :
- When the test add updates, it will be written to tlog-
- After the core is restarted, it will replay the updates from tlog-
- In the same time, the test add another DEQ, because the ulog is not active, 
DUP will write this DEQ to another file ( tlog-0001, buffering updates) and 
ignore apply this DEQ to IW.
{code:title=DistributedUpdateProcess.java|borderStyle=solid}
// we're not in an active state, and this update isn't from a replay, so buffer 
it.
cmd.setFlags(cmd.getFlags() | UpdateCommand.BUFFERING);
ulog.add(cmd);
{code}
- After LogReplay finish, we call a commit, which will write a commit update at 
the end of tlog-0001

So this DEQ update will never be replayed ( because it belong tlog-0001 not 
tlog- ), and it've never been applied to IW, so that DEQ update is lost.

But this do not mean we have a problem with SolrCloud mode or single instance 
mode. 
In SolrCloud mode, when a replica run recoverFromLog, replica in this time 
period will have state = DOWN, so It won't receive any updates.

In single instance mode, we will run in leader logic, so the DEQ is applied to 
IW immediately ( along with update {{ulog.deleteByQueries}} ).

But in TestRecovery, we kinda mixed up single instance code path along with 
SolrCloud mode code path, so we end up with the fail.

> log replay redundently (pre-)applies DBQs as if they were out of order
> --
>
> Key: SOLR-9941
> URL: https://issues.apache.org/jira/browse/SOLR-9941
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9941.hoss-test-experiment.patch, SOLR-9941.patch, 
> SOLR-9941.patch, SOLR-9941.patch
>
>
> There's kind of an odd situation that arises when a Solr node starts up 
> (after a crash) and tries to recover from it's tlog that causes deletes to be 
> redundantly & excessively applied -- at a minimum it causes confusing really 
> log messages
> * {{UpdateLog.init(...)}} creates {{TransactionLog}} instances for the most 
> recent log files found (based on numRecordsToKeep) and then builds a 
> {{RecentUpdates}} instance from them
> * Delete entries from the {{RecentUpdates}} are used to populate 2 lists:
> ** {{deleteByQueries}}
> ** {{oldDeletes}} (for deleteById).
> * Then when {{UpdateLog.recoverFromLog}} is called a {{LogReplayer}} is used 
> to replay any (uncommited) {{TransactionLog}} enteries
> ** during replay {{UpdateLog}} delegates to the UpdateRequestProcessorChain 
> to for the various adds/deletes, etc...
> ** when an add makes it to {{RunUpdateProcessor}} it delegates to 
> {{DirectUpdateHandler2}}, which (independent of the fact that we're in log 
> replay) calls {{UpdateLog.getDBQNewer}} for every add, looking for any 
> "Reordered" deletes that have a version greater then the add
> *** if it finds _any_ DBQs "newer" then the document being added, it does a 
> low level {{IndexWriter.updateDocument}} and then immediately executes _all_ 
> the newer DBQs ... _once per add_
> ** these deletes are *also* still executed as part of the normal tlog replay, 
> because they are in the tlog.
>

[jira] [Comment Edited] (SOLR-9941) log replay redundently (pre-)applies DBQs as if they were out of order

2017-01-10 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat edited comment on SOLR-9941 at 1/10/17 9:11 AM:
-

Here are the reason to explain why Hoss's test fails :
- When the test add updates, it will be written to tlog-
- After the core is restarted, it will replay the updates from tlog-
- In the same time, the test add another DEQ, because the ulog is not active, 
DUP will write this DEQ to another file ( tlog-0001, buffering updates) and 
ignore apply this DEQ to IW.
{code:title=DistributedUpdateProcess.java|borderStyle=solid}
// we're not in an active state, and this update isn't from a replay, so buffer 
it.
cmd.setFlags(cmd.getFlags() | UpdateCommand.BUFFERING);
ulog.add(cmd);
{code}
- After LogReplay finish, we call a commit, which will write a commit update at 
the end of tlog-0001

So this DEQ update will never be replayed ( because it belong tlog-0001 not 
tlog- ), and it've never been applied to IW, so that DEQ update is lost.

But this do not mean we have a problem with SolrCloud mode or single instance 
mode. 
In SolrCloud mode, when a replica run recoverFromLog, replica in this time 
period will have state = DOWN, so It won't receive any updates.

In single instance mode, we will run in leader logic, so the DEQ is applied to 
IW immediately ( along with update {{ulog.deleteByQueries}} ).

But in TestRecovery, we kinda mixed up single instance code path along with 
SolrCloud mode code path, so we end up with the fail.


was (Author: caomanhdat):
Here are the reason to explain why Hoss's test fails :
- When the test add updates, it will be written to tlog-
- After the core is restarted, it will replay the updates from tlog-
- In the same time, the test add another DEQ, because the ulog is on buffering 
mode, DUP will write this DEQ to another file ( tlog-0001) and ignore apply 
this DEQ to IW.
- After LogReplay finish, we call a commit, which will write a commit update at 
the end of tlog-0001

So this DEQ update will never be replayed ( because it belong tlog-0001 not 
tlog- ), and it've never been applied to IW, so that DEQ update is lost.
Even we restart the core, to hoping that it will replay tlog-0001, but because 
we write an commit at the end of tlog-0001, tlog-0001 will never be replayed.

So I think this fail belong to another issue.

> log replay redundently (pre-)applies DBQs as if they were out of order
> --
>
> Key: SOLR-9941
> URL: https://issues.apache.org/jira/browse/SOLR-9941
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9941.hoss-test-experiment.patch, SOLR-9941.patch, 
> SOLR-9941.patch, SOLR-9941.patch
>
>
> There's kind of an odd situation that arises when a Solr node starts up 
> (after a crash) and tries to recover from it's tlog that causes deletes to be 
> redundantly & excessively applied -- at a minimum it causes confusing really 
> log messages
> * {{UpdateLog.init(...)}} creates {{TransactionLog}} instances for the most 
> recent log files found (based on numRecordsToKeep) and then builds a 
> {{RecentUpdates}} instance from them
> * Delete entries from the {{RecentUpdates}} are used to populate 2 lists:
> ** {{deleteByQueries}}
> ** {{oldDeletes}} (for deleteById).
> * Then when {{UpdateLog.recoverFromLog}} is called a {{LogReplayer}} is used 
> to replay any (uncommited) {{TransactionLog}} enteries
> ** during replay {{UpdateLog}} delegates to the UpdateRequestProcessorChain 
> to for the various adds/deletes, etc...
> ** when an add makes it to {{RunUpdateProcessor}} it delegates to 
> {{DirectUpdateHandler2}}, which (independent of the fact that we're in log 
> replay) calls {{UpdateLog.getDBQNewer}} for every add, looking for any 
> "Reordered" deletes that have a version greater then the add
> *** if it finds _any_ DBQs "newer" then the document being added, it does a 
> low level {{IndexWriter.updateDocument}} and then immediately executes _all_ 
> the newer DBQs ... _once per add_
> ** these deletes are *also* still executed as part of the normal tlog replay, 
> because they are in the tlog.
> Which means if you are recovering from a tlog with 90 addDocs, followed by 5 
> DBQs, then *each* of those 5 DBQs will each be executed 91 times -- and for 
> 90 of those executions, a DUH2 INFO log messages will say {{"Reordered DBQs 
> detected. ..."}} even tough the only reason they are out of order is because 
> Solr is deliberately applying them out of order.
> * At a minimum we should improve the log messages
> * Ideally we should stop (pre-emptively) applying these deletes during tlog 
> replay.



--
This message was

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

2017-01-10 Thread Policeman Jenkins Server

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

1 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.GeneratedConstructorAccessor130.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:753)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:930)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:823)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)  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.GeneratedConstructorAccessor130.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:753)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:815)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1065)
at org.apache.solr.core.SolrCore.(SolrCore.java:930)
at org.apache.solr.core.SolrCore.(SolrCore.java:823)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:889)
at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:541)
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([8F6078DCBC564764]: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:269)
at sun.reflect.GeneratedMethodAccessor32.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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 667 - Still Unstable

2017-01-10 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/667/

1 tests failed.
FAILED:  org.apache.solr.search.TestRecovery.testBuffering

Error Message:
expected:<6> but was:<10>

Stack Trace:
java.lang.AssertionError: expected:<6> but was:<10>
at 
__randomizedtesting.SeedInfo.seed([CB39477825D67A13:D6D7E953848FDB38]: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.solr.search.TestRecovery.testBuffering(TestRecovery.java:284)
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 java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11910 lines...]
   [junit4] Suite: org.apache.solr.search.TestRecovery
   [junit4]   2> Creating dataDir:

[jira] [Resolved] (SOLR-9886) Add ability to turn off/on caches

[jira] [Commented] (SOLR-9950) TestRecovery.testBuffering() failure

[jira] [Updated] (SOLR-9950) TestRecovery.testBuffering() failure

[jira] [Assigned] (SOLR-9950) TestRecovery.testBuffering() failure

[jira] [Commented] (SOLR-9950) TestRecovery.testBuffering() failure

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

[jira] [Commented] (SOLR-9886) Add ability to turn off/on caches

[jira] [Commented] (SOLR-9886) Add ability to turn off/on caches

[jira] [Commented] (SOLR-9886) Add ability to turn off/on caches

[jira] [Commented] (SOLR-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work

[jira] [Updated] (SOLR-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work

JDK 9 EA Build 151 is available on java.net

[jira] [Commented] (SOLR-9941) log replay redundently (pre-)applies DBQs as if they were out of order

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[jira] [Comment Edited] (SOLR-9941) log replay redundently (pre-)applies DBQs as if they were out of order

[jira] [Comment Edited] (SOLR-9941) log replay redundently (pre-)applies DBQs as if they were out of order

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 667 - Still Unstable

< 1 2

101 - 118 of 118 matches

Site Navigation

Mail list logo

Footer information