[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[
https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701268#comment-13701268
]
Paul Elschot commented on LUCENE-5092:
--
To get to the beginning of a block that contains a given target document, we
need something like advanceToJustBefore(target).
So we do not really need backward iteration for this, we need forward iteration
by document blocks.
An implementation of this advanceToJustBefore can be made by using the current
advance() and than look back, as currently by prevSetBit(). Any implementation
could simply hide the retreat to the beginning of the block.
So how about this:
{code}
abstract class DocBlockIterator extends DocIdSetIterator {
abstract int advanceToJustBefore(int target);
}
{code}
?
> join: don't expect all filters to be FixedBitSet instances
> --
>
> Key: LUCENE-5092
> URL: https://issues.apache.org/jira/browse/LUCENE-5092
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/join
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
>
> The join module throws exceptions when the parents filter isn't a
> FixedBitSet. The reason is that the join module relies on prevSetBit to find
> the first child document given a parent ID.
> As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by
> exposing methods in the iterators to iterate backwards. When the join modules
> gets an iterator which isn't able to iterate backwards, it would just need to
> dump its content into another DocIdSet that supports backward iteration,
> FixedBitSet for example.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 6446 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6446/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch
Error Message:
Server at http://127.0.0.1:59720/onenodecollectioncore returned non ok
status:404, message:Can not find: /onenodecollectioncore/update
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at
http://127.0.0.1:59720/onenodecollectioncore returned non ok status:404,
message:Can not find: /onenodecollectioncore/update
at
__randomizedtesting.SeedInfo.seed([A728019BF1DCE27:8B940E01C842AE1B]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
at
org.apache.solr.cloud.BasicDistributedZk2Test.testNodeWithoutCollectionForwarding(BasicDistributedZk2Test.java:196)
at
org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:88)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:835)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedt
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4119 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4119/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=2445, name=recoveryCmdExecutor-995-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=2445, name=recoveryCmdExecutor-995-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([5D53C92A2B308751]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=2445, name=recoveryCmdExecutor-995-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701303#comment-13701303 ] Alan Woodward commented on SOLR-4948: - Thanks Uwe, Erick. I'll backport both of these this weekend. > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 612 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/612/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: collection already exists: awholynewcollection_1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: collection already exists: awholynewcollection_1 at __randomizedtesting.SeedInfo.seed([CAF4FABAF005C63:8D49C1B3D85F3C5F]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:264) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:318) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1522) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:438) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:146) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:835) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertion
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701316#comment-13701316 ] Erick Erickson commented on SOLR-4948: -- BTW, in case I didn't say it, this was timely. I had to, you guessed it, create a core container that didn't make all the assumptions built into TestHarness. This will make testing core-less setups wy easier. Thanks for tackling this! > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2112) Solrj should support streaming response
[ https://issues.apache.org/jira/browse/SOLR-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701317#comment-13701317 ] Mikhail Khludnev commented on SOLR-2112: fwiw, server side streaming is out-of scope of this issue. Some time ago I did a hack to allow streaming response during collecting results, if somebody need it, feel free to raise an issue. there is the code https://github.com/m-khl/solr-patches/compare/streaming > Solrj should support streaming response > --- > > Key: SOLR-2112 > URL: https://issues.apache.org/jira/browse/SOLR-2112 > Project: Solr > Issue Type: New Feature > Components: clients - java >Reporter: Ryan McKinley > Fix For: 4.0-ALPHA > > Attachments: SOLR-2112-StreamingSolrj.patch, > SOLR-2112-StreamingSolrj.patch, SOLR-2112-StreamingSolrj.patch > > > The solrj API should optionally support streaming documents. > Rather then putting all results into a SolrDocumentList, sorlj should be able > to call a callback function after each document is parsed. This would allow > someone to call query.setRows( Integer.MAX_INT ) and get each result to the > client without loading them all into memory. > For starters, I think the important things to stream are SolrDocuments, but > down the road, this could also stream other things (consider reading all > terms from the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701318#comment-13701318 ] Uwe Schindler commented on SOLR-4948: - Thanks Alan, I will help you on any problems! I hope SOLR-5009 is obvious, why it is a bad idea to lazyly create SolrResourceLoaders. As Erick said, this might be the issue for the recent permgen issues on trunk! Currently I am investigating all other places where Solr creates SolrResourceLoader but does not close it. The only remaining part is SolrCore.reload(), I have to figure out if the old Core is correctly closed and also closes the ResourceLoader! > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4898) Flesh out the Schema REST API
[ https://issues.apache.org/jira/browse/SOLR-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701319#comment-13701319 ] Grant Ingersoll commented on SOLR-4898: --- [~steve_rowe] What's involved w/ adding copy fields? Do you have anything under way there? > Flesh out the Schema REST API > - > > Key: SOLR-4898 > URL: https://issues.apache.org/jira/browse/SOLR-4898 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Affects Versions: 4.4 >Reporter: Steve Rowe > > As of Solr 4.4, the Solr Schema Rest API provides read access to all schema > elements (SOLR-4503, SOLR-4658, SOLR-4537, SOLR-4623), and the ability to > dynamically add new fields (SOLR-3251). See the wiki for documentation: > [http://wiki.apache.org/solr/SchemaRESTAPI]. > This is an umbrella issue to capture all future additions to the schema REST > API, including: > # adding dynamic fields > # adding field types > # adding copy field directives > # enabling wholesale replacement by PUTing a new schema. > # modifying fields, dynamic fields, field types, and copy field directives > # removing fields, dynamic fields, field types, and copy field directives > # modifying all remaining aspects of the schema: Name, Version, Unique Key, > Global Similarity, and Default Query Operator > I think the first three will be the easiest. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5010) Add REST support for Copy Fields
[ https://issues.apache.org/jira/browse/SOLR-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-5010: - Assignee: Grant Ingersoll > Add REST support for Copy Fields > > > Key: SOLR-5010 > URL: https://issues.apache.org/jira/browse/SOLR-5010 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 5.0, 4.4 > > > Per SOLR-4898, adding copy field support. Should be simply a new parameter > to the PUT/POST with the name of the target to copy to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5010) Add REST support for Copy Fields
Grant Ingersoll created SOLR-5010: - Summary: Add REST support for Copy Fields Key: SOLR-5010 URL: https://issues.apache.org/jira/browse/SOLR-5010 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Grant Ingersoll Fix For: 5.0, 4.4 Per SOLR-4898, adding copy field support. Should be simply a new parameter to the PUT/POST with the name of the target to copy to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5011) Manage to close all ResourceLoaders when cores are unloaded/reloaded
Uwe Schindler created SOLR-5011: --- Summary: Manage to close all ResourceLoaders when cores are unloaded/reloaded Key: SOLR-5011 URL: https://issues.apache.org/jira/browse/SOLR-5011 Project: Solr Issue Type: Bug Reporter: Uwe Schindler Followup of SOLR-5009 and SOLR-4948: I fixed almost all places where Solr creates SolrResourceLoaders lazily. Solr should only create a SolrResourceLoader when the CoreContainer starts up and when a new Core is created (as a child SolrResourceLoader). There are already issues open to fix the hierarchy, but this issue is about corrcetly closing the SolrResourceLoader, as this is mandatory for correct class unloading and freeing up system resources, including closing JAR files (to be able to delete them on windows). SolrCore currently does not close its own SolrResourceLoader and the logic for reopening is un-understandable to me. In addition the SolrResourceLoader is shared by the config and the core and sometimes also the reopened core. I have no idea when it can be closed safely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5011) Manage to close all ResourceLoaders when cores are unloaded/reloaded
[ https://issues.apache.org/jira/browse/SOLR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-5011: Component/s: multicore Fix Version/s: 4.4 5.0 > Manage to close all ResourceLoaders when cores are unloaded/reloaded > > > Key: SOLR-5011 > URL: https://issues.apache.org/jira/browse/SOLR-5011 > Project: Solr > Issue Type: Bug > Components: multicore >Reporter: Uwe Schindler > Fix For: 5.0, 4.4 > > > Followup of SOLR-5009 and SOLR-4948: I fixed almost all places where Solr > creates SolrResourceLoaders lazily. Solr should only create a > SolrResourceLoader when the CoreContainer starts up and when a new Core is > created (as a child SolrResourceLoader). There are already issues open to fix > the hierarchy, but this issue is about corrcetly closing the > SolrResourceLoader, as this is mandatory for correct class unloading and > freeing up system resources, including closing JAR files (to be able to > delete them on windows). > SolrCore currently does not close its own SolrResourceLoader and the logic > for reopening is un-understandable to me. In addition the SolrResourceLoader > is shared by the config and the core and sometimes also the reopened core. I > have no idea when it can be closed safely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701324#comment-13701324 ] Uwe Schindler commented on SOLR-4948: - I opened SOLR-4914 to correctly close SolrResourceLoaders for SolrCore and reloaded SolrCores. Its a mess, I have no idea how to handle resource tracking! > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5010) Add REST support for Copy Fields
[ https://issues.apache.org/jira/browse/SOLR-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-5010: -- Attachment: SOLR-5010.patch First start at this, pretty straightforward, but needs more tests. Adds an option called copyFields, which can take a comma separated list of targets to copy the source to. See the TestManagedSchemaFieldResource for an example. > Add REST support for Copy Fields > > > Key: SOLR-5010 > URL: https://issues.apache.org/jira/browse/SOLR-5010 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 5.0, 4.4 > > Attachments: SOLR-5010.patch > > > Per SOLR-4898, adding copy field support. Should be simply a new parameter > to the PUT/POST with the name of the target to copy to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5010) Add REST support for Copy Fields
[ https://issues.apache.org/jira/browse/SOLR-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-5010: -- Attachment: SOLR-5010.patch Fix PUT option and add a test for it. I think this is ready to go, but going to wait for others to double check, as I am not sure on how the hand off of the old schema to the new schema is managed and if adding the registerCopyField where I did is the right thing to do. > Add REST support for Copy Fields > > > Key: SOLR-5010 > URL: https://issues.apache.org/jira/browse/SOLR-5010 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 5.0, 4.4 > > Attachments: SOLR-5010.patch, SOLR-5010.patch > > > Per SOLR-4898, adding copy field support. Should be simply a new parameter > to the PUT/POST with the name of the target to copy to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-4982:
-
Attachment: SOLR-4982.patch
Final patch, committing momentarily
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch,
> SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701360#comment-13701360
]
ASF subversion and git services commented on SOLR-4982:
---
Commit 1500284 from [~erickoerickson]
[ https://svn.apache.org/r1500284 ]
Fix for SOLR-4982, creating cores with sysprops does not dereference them
properly
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch,
> SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701361#comment-13701361
]
Erick Erickson commented on SOLR-4982:
--
trunk: r - 1500284
Needs to wait on a couple of other patches to be merged into 4.x to commit
there.
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch,
> SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4120 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4120/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=3572, name=recoveryCmdExecutor-1393-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=3572, name=recoveryCmdExecutor-1393-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([396FD69CF9ADA3F4]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=3572, name=recoveryCmdExecutor-1393-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:39
[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 307 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/307/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=1627, name=recoveryCmdExecutor-562-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=1627, name=recoveryCmdExecutor-562-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) at __randomizedtesting.SeedInfo.seed([6440643D4258590]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=1627, name=recoveryCmdExecutor-562-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701392#comment-13701392 ] ASF subversion and git services commented on SOLR-4948: --- Commit 1500315 from [~romseygeek] [ https://svn.apache.org/r1500315 ] SOLR-4948, SOLR-5009: Tidy up CoreContainer construction logic > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5009) CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not close all of them
[ https://issues.apache.org/jira/browse/SOLR-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701393#comment-13701393 ] ASF subversion and git services commented on SOLR-5009: --- Commit 1500315 from [~romseygeek] [ https://svn.apache.org/r1500315 ] SOLR-4948, SOLR-5009: Tidy up CoreContainer construction logic > CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not > close all of them > -- > > Key: SOLR-5009 > URL: https://issues.apache.org/jira/browse/SOLR-5009 > Project: Solr > Issue Type: Bug > Components: multicore >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, 4.4 > > Attachments: SOLR-5009.patch > > > Windows fails to delete files when they are open. CoreContainer opens a > second SolrResourceLoader (implicit) when calling ConfigSolr.fromFile(). It > should not do this and use the main loader, whcih is closed on shutdown. > This will remove the support for implicit ResourceLoader in ConfigSolr, > preventing multiple classloaders for the same solr home. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-4948. - Resolution: Fixed Thanks all! > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701395#comment-13701395 ] ASF subversion and git services commented on SOLR-4948: --- Commit 1500316 from [~romseygeek] [ https://svn.apache.org/r1500316 ] Move SOLR-4948 CHANGES.txt entry to 4.4 > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5094) add a ramBytesUsed to OrdinalMap
Robert Muir created LUCENE-5094: --- Summary: add a ramBytesUsed to OrdinalMap Key: LUCENE-5094 URL: https://issues.apache.org/jira/browse/LUCENE-5094 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-5094.patch I think this would be useful. it could e.g. be exposed via SortedSetDocValuesReaderState and so on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5094) add a ramBytesUsed to OrdinalMap
[ https://issues.apache.org/jira/browse/LUCENE-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5094: Attachment: LUCENE-5094.patch here's the patch. its just summing across the ramBytesUsed of its packed ints structures. > add a ramBytesUsed to OrdinalMap > > > Key: LUCENE-5094 > URL: https://issues.apache.org/jira/browse/LUCENE-5094 > Project: Lucene - Core > Issue Type: Task >Reporter: Robert Muir > Attachments: LUCENE-5094.patch > > > I think this would be useful. it could e.g. be exposed via > SortedSetDocValuesReaderState and so on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #902: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/902/ 2 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=491, name=recoveryCmdExecutor-117-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=491, name=recoveryCmdExecutor-117-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([E7974CCAE13B4B72]:0) FAILED: org.apache.solr.cloud.BasicDistributedZkTest.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated: 1) Thread[id=491, name=recoveryCmdExecutor-117-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java
[jira] [Created] (LUCENE-5095) Add useful toString()s to DocValues impls
Robert Muir created LUCENE-5095:
---
Summary: Add useful toString()s to DocValues impls
Key: LUCENE-5095
URL: https://issues.apache.org/jira/browse/LUCENE-5095
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Currently, you have no insight into what these are doing (what kind of
compression does your numerics have, how much RAM are the datastructures taking
up, so on.
So I think we should add some cheap toString's (nothing heavy), things like
{code}
@Override
public String toString() {
return "Lucene42Numeric(compression=TABLE,bpv=" + bitsPerValue)";
}
{code}
and so on. Maybe we could think about printing them from CheckIndex when
verbose=true too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701399#comment-13701399 ] Uwe Schindler commented on SOLR-4948: - Thanks! Commit looks fine, I think Windows tests will succeed also on 4.x :-) > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, > SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5009) CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not close all of them
[ https://issues.apache.org/jira/browse/SOLR-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-5009. - Resolution: Fixed > CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not > close all of them > -- > > Key: SOLR-5009 > URL: https://issues.apache.org/jira/browse/SOLR-5009 > Project: Solr > Issue Type: Bug > Components: multicore >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, 4.4 > > Attachments: SOLR-5009.patch > > > Windows fails to delete files when they are open. CoreContainer opens a > second SolrResourceLoader (implicit) when calling ConfigSolr.fromFile(). It > should not do this and use the main loader, whcih is closed on shutdown. > This will remove the support for implicit ResourceLoader in ConfigSolr, > preventing multiple classloaders for the same solr home. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5009) CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not close all of them
[ https://issues.apache.org/jira/browse/SOLR-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701401#comment-13701401 ] Robert Muir commented on SOLR-5009: --- Thanks Uwe/Alan! > CoreContainer instantiates 2 SolrResourceLoaders (implicit) but does not > close all of them > -- > > Key: SOLR-5009 > URL: https://issues.apache.org/jira/browse/SOLR-5009 > Project: Solr > Issue Type: Bug > Components: multicore >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 5.0, 4.4 > > Attachments: SOLR-5009.patch > > > Windows fails to delete files when they are open. CoreContainer opens a > second SolrResourceLoader (implicit) when calling ConfigSolr.fromFile(). It > should not do this and use the main loader, whcih is closed on shutdown. > This will remove the support for implicit ResourceLoader in ConfigSolr, > preventing multiple classloaders for the same solr home. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Several builds hanging pecause of permgen
Another one: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6375/console I was only able to kill the JVM with kill -9 I am sure, it's horrible slowdoop! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, July 05, 2013 3:59 PM > To: dev@lucene.apache.org > Subject: Several builds hanging pecause of permgen > > Several Jenkins builds now hang because of permgen. The runner JVM is > dead (can only be killed by -9), last example: > > http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6360/console > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5095) Add useful toString()s to DocValues impls
[
https://issues.apache.org/jira/browse/LUCENE-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701403#comment-13701403
]
Otis Gospodnetic commented on LUCENE-5095:
--
+1. Not sure if Luke + Solr's Luke expose this either, but would be good to
have them expose this info as well.
> Add useful toString()s to DocValues impls
> -
>
> Key: LUCENE-5095
> URL: https://issues.apache.org/jira/browse/LUCENE-5095
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>
> Currently, you have no insight into what these are doing (what kind of
> compression does your numerics have, how much RAM are the datastructures
> taking up, so on.
> So I think we should add some cheap toString's (nothing heavy), things like
> {code}
> @Override
> public String toString() {
> return "Lucene42Numeric(compression=TABLE,bpv=" + bitsPerValue)";
> }
> {code}
> and so on. Maybe we could think about printing them from CheckIndex when
> verbose=true too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5095) Add useful toString()s to DocValues impls
[
https://issues.apache.org/jira/browse/LUCENE-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701404#comment-13701404
]
Robert Muir commented on LUCENE-5095:
-
I hesitate to pull docvalues + toString from such places, because they are lazy
loaded and with some implementations could cause things to be loaded into RAM.
but I mentioned checkindex since its going to do this to verify them anyway...
> Add useful toString()s to DocValues impls
> -
>
> Key: LUCENE-5095
> URL: https://issues.apache.org/jira/browse/LUCENE-5095
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>
> Currently, you have no insight into what these are doing (what kind of
> compression does your numerics have, how much RAM are the datastructures
> taking up, so on.
> So I think we should add some cheap toString's (nothing heavy), things like
> {code}
> @Override
> public String toString() {
> return "Lucene42Numeric(compression=TABLE,bpv=" + bitsPerValue)";
> }
> {code}
> and so on. Maybe we could think about printing them from CheckIndex when
> verbose=true too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1769 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1769/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=1761, name=recoveryCmdExecutor-817-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=1761, name=recoveryCmdExecutor-817-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) at __randomizedtesting.SeedInfo.seed([36812CB9351C5A4C]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=1761, name=recoveryCmdExecutor-817-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b94) - Build # 6450 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6450/ Java: 64bit/jdk1.8.0-ea-b94 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,183,312 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 13,107,120 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 288 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 216 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,183,312 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 13,107,120 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 288 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 216 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([D7AAC6C542EF8923]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10297 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:389: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:369: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:181: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:443: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1246: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:890: There were test failures: 316 suites, 1330 tests, 1 suite-level error, 23 ignored (10 assumptions) Total time: 36 minutes 45 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.8.0-ea-b94 -XX:+UseCompressedOops -XX:+UseSerialGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4914) Factor out core discovery and persistence logic
[ https://issues.apache.org/jira/browse/SOLR-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-4914: Attachment: SOLR-4914.patch Latest status. There are still some failing tests, and I need to add some new generic persistence tests. > Factor out core discovery and persistence logic > --- > > Key: SOLR-4914 > URL: https://issues.apache.org/jira/browse/SOLR-4914 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.0 >Reporter: Erick Erickson >Assignee: Alan Woodward > Attachments: SOLR-4914.patch, SOLR-4914.patch, SOLR-4914.patch, > SOLR-4914.patch > > > Alan Woodward has done some work to refactor how core persistence works that > we should work on going forward that I want to separate from a shorter-term > tactical problem (See SOLR-4910). > I'm attaching Alan's patch to this JIRA and we'll carry it forward separately > from 4910. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_25) - Build # 3009 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3009/ Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,050,712 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 12,759,880 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 456 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 328 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 232 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 80 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 72 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,050,712 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 12,759,880 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 456 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 328 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 232 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 80 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 72 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([47FC76297C355C54]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10292 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:389: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:369: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:39: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:181: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:443: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1246: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:890: There were test failures: 316 suites, 1330 tests, 1 suite-level error, 39 ignored (11 assumptions) Total time: 74 minutes 28 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_25) - Build # 6451 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6451/ Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 20,551,712 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 21,751,464 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 456 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 232 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 80 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 72 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 20,551,712 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 21,751,464 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 456 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 232 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 80 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 72 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([55B799A3CB9BA3E2]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10268 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:389: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:369: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:181: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:443: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1246: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:890: There were test failures: 316 suites, 1330 tests, 1 suite-level error, 20 ignored (13 assumptions) Total time: 37 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -XX:+UseSerialGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4121 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4121/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.AliasIntegrationTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.AliasIntegrationTest: 1) Thread[id=925, name=recoveryCmdExecutor-731-thread-1, state=RUNNABLE, group=TGRP-AliasIntegrationTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.AliasIntegrationTest: 1) Thread[id=925, name=recoveryCmdExecutor-731-thread-1, state=RUNNABLE, group=TGRP-AliasIntegrationTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([5EEDC73677A9EA52]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.AliasIntegrationTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=925, name=recoveryCmdExecutor-731-thread-1, state=RUNNABLE, group=TGRP-AliasIntegrationTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.n
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_25) - Build # 6377 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6377/ Java: 64bit/jdk1.7.0_25 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate Error Message: expected:<[in]active> but was:<[]active> Stack Trace: org.junit.ComparisonFailure: expected:<[in]active> but was:<[]active> at __randomizedtesting.SeedInfo.seed([36EEB182F3EFC99E:E68C3CCEAD3A131A]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:183) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10742 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-S
RE: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/core/ core/src/java/org/apache/solr/handler/admin/ core/src/test/org/apache/solr/handler/admin/ test-framework/sr
This seems to cause a memory leak, see recently failing Jenkins tests!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: er...@apache.org [mailto:er...@apache.org]
> Sent: Saturday, July 06, 2013 4:46 PM
> To: comm...@lucene.apache.org
> Subject: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./
> core/src/java/org/apache/solr/core/
> core/src/java/org/apache/solr/handler/admin/
> core/src/test/org/apache/solr/handler/admin/ test-
> framework/src/java/org/apache/solr/
>
> Author: erick
> Date: Sat Jul 6 14:45:47 2013
> New Revision: 1500284
>
> URL: http://svn.apache.org/r1500284
> Log:
> Fix for SOLR-4982, creating cores with sysprops does not dereference them
> properly
>
> Added:
>
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
> dminCreateDiscoverTest.java (with props)
> Modified:
> lucene/dev/trunk/solr/CHANGES.txt
>
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
> ava
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/CoreA
> dminHandler.java
>
> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
> dminHandlerTest.java
> lucene/dev/trunk/solr/test-
> framework/src/java/org/apache/solr/SolrTestCaseJ4.java
>
> Modified: lucene/dev/trunk/solr/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?rev=150
> 0284&r1=1500283&r2=1500284&view=diff
> ==
>
> --- lucene/dev/trunk/solr/CHANGES.txt (original)
> +++ lucene/dev/trunk/solr/CHANGES.txt Sat Jul 6 14:45:47 2013
> @@ -253,6 +253,12 @@ Bug Fixes
>
> * SOLR-5000: ManagedIndexSchema doesn't persist uniqueKey tag after
> calling addFields
>method. (Jun Ohtani, Steve Rowe)
> +
> +* SOLR-4982: Creating a core while referencing system properties looks
> +like it loses files
> + Actually, instanceDir, config, dataDir and schema are not
> +dereferenced properly
> + when creating cores that reference sys vars (e.g. &dataDir=${dir}).
> +In the dataDir
> + case in particular this leads to the index being put in a directory
> +literally named
> + ${dir} but on restart the sysvar will be properly dereferenced.
>
> Optimizations
> --
>
> Modified:
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
> ava
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
> che/solr/core/CoreDescriptor.java?rev=1500284&r1=1500283&r2=1500284&v
> iew=diff
> ==
>
> ---
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
> ava (original)
> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescrip
> +++ tor.java Sat Jul 6 14:45:47 2013
> @@ -46,7 +46,7 @@ public class CoreDescriptor {
>public static final String CORE_TRANSIENT = "transient";
>public static final String CORE_NODE_NAME = "coreNodeName";
>
> - static final String[] standardPropNames = {
> + public static final String[] standardPropNames = {
>CORE_NAME,
>CORE_CONFIG,
>CORE_INSTDIR,
> @@ -65,7 +65,7 @@ public class CoreDescriptor {
>// them individually.
>private Properties coreProperties = new Properties();
>
> - //TODO: 5.0 remove this, this is solely a hack for persistence.
> + //TODO: 5.0 remove this, this is solely a hack for persistence. And perhaps
> creating cores in discovery mode?
>private Properties createdProperties = new Properties();
>
>private boolean loadedImplicit = false;
>
> Modified:
> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
> che/solr/core/SolrCore.java?rev=1500284&r1=1500283&r2=1500284&view=di
> ff
> ==
>
> --- lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
> (original)
> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.ja
> +++ va Sat Jul 6 14:45:47 2013
> @@ -26,6 +26,7 @@ import java.io.Writer; import
> java.lang.reflect.Constructor; import java.net.URL; import
> java.util.ArrayList;
> +import java.util.Arrays;
> import java.util.Collection;
> import java.util.Collections;
> import java.util.Date;
> @@ -873,6 +874,18 @@ public final class SolrCore implements S
>propFile.getParentFile().mkdirs();
>Properties props = new Properties();
>props.put("name", cd.getName());
> +
> + // This must be being created since there's no file here already. So
> write
> out all of the params we were
> + // created with. This _may_ overwrite the name above, but that's OK.
> + Collection stds = new
> H
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b94) - Build # 6452 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6452/ Java: 64bit/jdk1.8.0-ea-b94 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate Error Message: expected:<[in]active> but was:<[]active> Stack Trace: org.junit.ComparisonFailure: expected:<[in]active> but was:<[]active> at __randomizedtesting.SeedInfo.seed([577F88AB76043E43:871D05E728D1E4C7]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.SliceStateUpdateTest.testSliceStateUpdate(SliceStateUpdateTest.java:183) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10555 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lu
Re: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/core/ core/src/java/org/apache/solr/handler/admin/ core/src/test/org/apache/solr/handler/admin/ test-framework/sr
Yeah, just saw this and starting to look. I might have a clue, we'll see.
Erick
On Sat, Jul 6, 2013 at 7:10 PM, Uwe Schindler wrote:
> This seems to cause a memory leak, see recently failing Jenkins tests!
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: er...@apache.org [mailto:er...@apache.org]
>> Sent: Saturday, July 06, 2013 4:46 PM
>> To: comm...@lucene.apache.org
>> Subject: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./
>> core/src/java/org/apache/solr/core/
>> core/src/java/org/apache/solr/handler/admin/
>> core/src/test/org/apache/solr/handler/admin/ test-
>> framework/src/java/org/apache/solr/
>>
>> Author: erick
>> Date: Sat Jul 6 14:45:47 2013
>> New Revision: 1500284
>>
>> URL: http://svn.apache.org/r1500284
>> Log:
>> Fix for SOLR-4982, creating cores with sysprops does not dereference them
>> properly
>>
>> Added:
>>
>> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
>> dminCreateDiscoverTest.java (with props)
>> Modified:
>> lucene/dev/trunk/solr/CHANGES.txt
>>
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>>
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/CoreA
>> dminHandler.java
>>
>> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
>> dminHandlerTest.java
>> lucene/dev/trunk/solr/test-
>> framework/src/java/org/apache/solr/SolrTestCaseJ4.java
>>
>> Modified: lucene/dev/trunk/solr/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?rev=150
>> 0284&r1=1500283&r2=1500284&view=diff
>> ==
>>
>> --- lucene/dev/trunk/solr/CHANGES.txt (original)
>> +++ lucene/dev/trunk/solr/CHANGES.txt Sat Jul 6 14:45:47 2013
>> @@ -253,6 +253,12 @@ Bug Fixes
>>
>> * SOLR-5000: ManagedIndexSchema doesn't persist uniqueKey tag after
>> calling addFields
>>method. (Jun Ohtani, Steve Rowe)
>> +
>> +* SOLR-4982: Creating a core while referencing system properties looks
>> +like it loses files
>> + Actually, instanceDir, config, dataDir and schema are not
>> +dereferenced properly
>> + when creating cores that reference sys vars (e.g. &dataDir=${dir}).
>> +In the dataDir
>> + case in particular this leads to the index being put in a directory
>> +literally named
>> + ${dir} but on restart the sysvar will be properly dereferenced.
>>
>> Optimizations
>> --
>>
>> Modified:
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
>> che/solr/core/CoreDescriptor.java?rev=1500284&r1=1500283&r2=1500284&v
>> iew=diff
>> ==
>>
>> ---
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava (original)
>> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescrip
>> +++ tor.java Sat Jul 6 14:45:47 2013
>> @@ -46,7 +46,7 @@ public class CoreDescriptor {
>>public static final String CORE_TRANSIENT = "transient";
>>public static final String CORE_NODE_NAME = "coreNodeName";
>>
>> - static final String[] standardPropNames = {
>> + public static final String[] standardPropNames = {
>>CORE_NAME,
>>CORE_CONFIG,
>>CORE_INSTDIR,
>> @@ -65,7 +65,7 @@ public class CoreDescriptor {
>>// them individually.
>>private Properties coreProperties = new Properties();
>>
>> - //TODO: 5.0 remove this, this is solely a hack for persistence.
>> + //TODO: 5.0 remove this, this is solely a hack for persistence. And
>> perhaps
>> creating cores in discovery mode?
>>private Properties createdProperties = new Properties();
>>
>>private boolean loadedImplicit = false;
>>
>> Modified:
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
>> che/solr/core/SolrCore.java?rev=1500284&r1=1500283&r2=1500284&view=di
>> ff
>> ==
>>
>> --- lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>> (original)
>> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.ja
>> +++ va Sat Jul 6 14:45:47 2013
>> @@ -26,6 +26,7 @@ import java.io.Writer; import
>> java.lang.reflect.Constructor; import java.net.URL; import
>> java.util.ArrayList;
>> +import java.util.Arrays;
>> import java.util.Collection;
>> import java.util.Collections;
>> import java.util.Date;
>> @@ -873,6 +874,18 @@ public final class SolrCore implements S
>>propFile.getParentFile().mkdirs();
>>Properties props = new Properties();
>>props.
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_25) - Build # 6453 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6453/ Java: 32bit/jdk1.7.0_25 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 14,360,944 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 15,121,864 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 264 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 120 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 48 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 14,360,944 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 15,121,864 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 264 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 120 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 48 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([2C0993BCE8A4F304]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10239 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:389: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:369: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:181: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:443: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1246: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:890: There were test failures: 316 suites, 1330 tests, 1 suite-level error, 20 ignored (13 assumptions) Total time: 44 minutes 54 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_25 -client -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 630 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/630/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,857,344 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 13,706,752 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 280 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 240 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 12,857,344 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 13,706,752 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 280 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 240 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([3DD2340B41C5D50]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) REGRESSION: org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWritesLargeCache Error Message: Test failed on pass [9] Stack Trace: java.lang.AssertionError: Test failed on pass [9] at __randomizedtesting.SeedInfo.seed([3DD2340B41C5D50:9CFE21E3A95CFE9]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWrites(BlockDirectoryTest.java:163) at org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWritesLargeCache(BlockDirectoryTest.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_45) - Build # 6379 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6379/ Java: 64bit/jdk1.6.0_45 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 9266 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /var/lib/jenkins/tools/java/64bit/jdk1.6.0_45/jre/bin/java -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=BA6793FB52999E58 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.4 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/test/temp -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy -Dlucene.version=4.4-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=ISO-8859-1 -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/classes/test:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/commons-collections-3.2.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/hadoop-common-2.0.5-alpha-tests.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/hadoop-hdfs-2.0.5-alpha-tests.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/jersey-core-1.16.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/jetty-6.1.26.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/jetty-util-6.1.26.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/test-framework/lib/junit4-ant-2.0.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/test-files:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-solrj/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build/solr-core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/common/lucene-analyzers-common-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/lucene-codecs-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/highlighter/lucene-highlighter-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/memory/lucene-memory-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/misc/lucene-misc-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/spatial/lucene-spatial-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/suggest/lucene-suggest-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/grouping/lucene-grouping-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/queries/lucene-queries-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/queryparser/lucene-queryparser-4.4-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/cglib-nodep-2.2.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/commons-cli-1.2.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/commons-codec-1.7.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/commons-configuration-1.6.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/commons-fileupload-1.2.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/commons-lang-2.6.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/concurrentlinkedhashmap-lru-1.2.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/core/lib/easymock-3.0.jar:/mnt/ssd/jenkins/wor
[jira] [Updated] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-4982:
-
Attachment: SOLR-4982-fixtest.patch
An attempt to fix the broken test.
Apply _after_ main patch.
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982-fixtest.patch, SOLR-4982.patch,
> SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701481#comment-13701481
]
ASF subversion and git services commented on SOLR-4982:
---
Commit 1500354 from [~erickoerickson]
[ https://svn.apache.org/r1500354 ]
Fix broken test checked in with SOLR-4982
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982-fixtest.patch, SOLR-4982.patch,
> SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_25) - Build # 6454 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6454/ Java: 64bit/jdk1.7.0_25 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 11,836,256 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 12,598,016 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 280 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 11,836,256 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 12,598,016 bytes, private static org.apache.solr.handler.admin.CoreAdminHandler org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.admin - 280 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 216 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 200 bytes, private static java.io.File org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.solrHomeDirectory - 128 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 64 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 64 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreSysProps - 56 bytes, private static java.lang.String org.apache.solr.handler.admin.CoreAdminCreateDiscoverTest.coreNormal at __randomizedtesting.SeedInfo.seed([594461DD0CC2CDAA]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 10227 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:389: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:369: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:39: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:181: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:443: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1246: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:890: There were test failures: 316 suites, 1330 tests, 1 suite-level error, 20 ignored (13 assumptions) Total time: 39 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_25 -XX:+UseCompressedOops -XX:+UseSerialGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/core/ core/src/java/org/apache/solr/handler/admin/ core/src/test/org/apache/solr/handler/admin/ test-framework/sr
OK, I was able to reproduce this on my machine and checked in what
appears to be a fix. But then I thought I'd handled this case before,
so we'll see what happens overnight.
On Sat, Jul 6, 2013 at 7:10 PM, Uwe Schindler wrote:
> This seems to cause a memory leak, see recently failing Jenkins tests!
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: er...@apache.org [mailto:er...@apache.org]
>> Sent: Saturday, July 06, 2013 4:46 PM
>> To: comm...@lucene.apache.org
>> Subject: svn commit: r1500284 - in /lucene/dev/trunk/solr: ./
>> core/src/java/org/apache/solr/core/
>> core/src/java/org/apache/solr/handler/admin/
>> core/src/test/org/apache/solr/handler/admin/ test-
>> framework/src/java/org/apache/solr/
>>
>> Author: erick
>> Date: Sat Jul 6 14:45:47 2013
>> New Revision: 1500284
>>
>> URL: http://svn.apache.org/r1500284
>> Log:
>> Fix for SOLR-4982, creating cores with sysprops does not dereference them
>> properly
>>
>> Added:
>>
>> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
>> dminCreateDiscoverTest.java (with props)
>> Modified:
>> lucene/dev/trunk/solr/CHANGES.txt
>>
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>>
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/CoreA
>> dminHandler.java
>>
>> lucene/dev/trunk/solr/core/src/test/org/apache/solr/handler/admin/CoreA
>> dminHandlerTest.java
>> lucene/dev/trunk/solr/test-
>> framework/src/java/org/apache/solr/SolrTestCaseJ4.java
>>
>> Modified: lucene/dev/trunk/solr/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?rev=150
>> 0284&r1=1500283&r2=1500284&view=diff
>> ==
>>
>> --- lucene/dev/trunk/solr/CHANGES.txt (original)
>> +++ lucene/dev/trunk/solr/CHANGES.txt Sat Jul 6 14:45:47 2013
>> @@ -253,6 +253,12 @@ Bug Fixes
>>
>> * SOLR-5000: ManagedIndexSchema doesn't persist uniqueKey tag after
>> calling addFields
>>method. (Jun Ohtani, Steve Rowe)
>> +
>> +* SOLR-4982: Creating a core while referencing system properties looks
>> +like it loses files
>> + Actually, instanceDir, config, dataDir and schema are not
>> +dereferenced properly
>> + when creating cores that reference sys vars (e.g. &dataDir=${dir}).
>> +In the dataDir
>> + case in particular this leads to the index being put in a directory
>> +literally named
>> + ${dir} but on restart the sysvar will be properly dereferenced.
>>
>> Optimizations
>> --
>>
>> Modified:
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
>> che/solr/core/CoreDescriptor.java?rev=1500284&r1=1500283&r2=1500284&v
>> iew=diff
>> ==
>>
>> ---
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescriptor.j
>> ava (original)
>> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreDescrip
>> +++ tor.java Sat Jul 6 14:45:47 2013
>> @@ -46,7 +46,7 @@ public class CoreDescriptor {
>>public static final String CORE_TRANSIENT = "transient";
>>public static final String CORE_NODE_NAME = "coreNodeName";
>>
>> - static final String[] standardPropNames = {
>> + public static final String[] standardPropNames = {
>>CORE_NAME,
>>CORE_CONFIG,
>>CORE_INSTDIR,
>> @@ -65,7 +65,7 @@ public class CoreDescriptor {
>>// them individually.
>>private Properties coreProperties = new Properties();
>>
>> - //TODO: 5.0 remove this, this is solely a hack for persistence.
>> + //TODO: 5.0 remove this, this is solely a hack for persistence. And
>> perhaps
>> creating cores in discovery mode?
>>private Properties createdProperties = new Properties();
>>
>>private boolean loadedImplicit = false;
>>
>> Modified:
>> lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>> URL:
>> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apa
>> che/solr/core/SolrCore.java?rev=1500284&r1=1500283&r2=1500284&view=di
>> ff
>> ==
>>
>> --- lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java
>> (original)
>> +++ lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.ja
>> +++ va Sat Jul 6 14:45:47 2013
>> @@ -26,6 +26,7 @@ import java.io.Writer; import
>> java.lang.reflect.Constructor; import java.net.URL; import
>> java.util.ArrayList;
>> +import java.util.Arrays;
>> import java.util.Collection;
>> import java.util.Collections;
>> import java.util.Date;
>> @@ -873,6 +874,18 @@ public final class SolrCore implements S
>>propF
[jira] [Commented] (SOLR-4982) Creating a core while referencing system properties looks like it loses files.
[
https://issues.apache.org/jira/browse/SOLR-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701486#comment-13701486
]
ASF subversion and git services commented on SOLR-4982:
---
Commit 1500359 from [~erickoerickson]
[ https://svn.apache.org/r1500359 ]
SOLR-4982 4x checkin, including the test fix (trunk r 1500354)
> Creating a core while referencing system properties looks like it loses files.
> --
>
> Key: SOLR-4982
> URL: https://issues.apache.org/jira/browse/SOLR-4982
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.3, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Blocker
> Attachments: SOLR-4982-fixtest.patch, SOLR-4982.patch,
> SOLR-4982.patch, SOLR-4982.patch, SOLR-4982.patch
>
>
> If you use the core admin handler to create core and reference system
> properties and index files without restarting Solr, your files are indexed to
> the wrong place.
> Say for instance I define a sys prop EOE=/Users/Erick/tmp and create a core
> with this request
> localhost:8983/solr/admin/cores?action=CREATE&name=coreZ&instanceDir=coreZ&dataDir=%24%7BEOE%7D
> where %24%7BEOE%7D is really ${EOE} after URL escaping. What gets preserved
> in solr.xml is correct, dataDir is set to ${EOE}. And if I restart Solr, then
> index documents, they wind up in /Users/Erick/tmp. This is as it should be.
> HOWEVER, if rather than immediately restart Solr I index some documents to
> CoreZ, they go in /CoreZ/${EOE}. The literal path is ${EOE},
> dollar sign, curly braces and all.
> How important is this to fix for 4.4?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1770 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1770/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=3627, name=recoveryCmdExecutor-1524-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=3627, name=recoveryCmdExecutor-1524-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) at __randomizedtesting.SeedInfo.seed([AE8DEE2A64F354F4]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=3627, name=recoveryCmdExecutor-1524-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4122 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4122/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=2550, name=recoveryCmdExecutor-987-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.BasicDistributedZkTest: 1) Thread[id=2550, name=recoveryCmdExecutor-987-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.SyncStrategy$1.run(SyncStrategy.java:291) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) at __randomizedtesting.SeedInfo.seed([CB3E67241855BEBF]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=2550, name=recoveryCmdExecutor-987-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
[jira] [Created] (SOLR-5012) optimize search with filter when filterCache is null
Robert Muir created SOLR-5012: - Summary: optimize search with filter when filterCache is null Key: SOLR-5012 URL: https://issues.apache.org/jira/browse/SOLR-5012 Project: Solr Issue Type: Improvement Reporter: Robert Muir Currently, this is very slow (it pulls bitsets and then intersects them after the fact). If you have no filterCache, it should be treated as if you specified cache=false implicitly and intersected with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5012) optimize search with filter when filterCache is null
[ https://issues.apache.org/jira/browse/SOLR-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-5012: -- Attachment: SOLR-5012.patch simple patch: easiest to just wrap the query as if the user specified cache=false, so that this situation still works correctly with any postfiltering or any of that. > optimize search with filter when filterCache is null > > > Key: SOLR-5012 > URL: https://issues.apache.org/jira/browse/SOLR-5012 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir > Attachments: SOLR-5012.patch > > > Currently, this is very slow (it pulls bitsets and then intersects them after > the fact). > If you have no filterCache, it should be treated as if you specified > cache=false implicitly and intersected with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
