[jira] [Commented] (SOLR-4698) "java.lang.OutOfMemoryError: Map failed" when run in JRE64
[ https://issues.apache.org/jira/browse/SOLR-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628907#comment-13628907 ] zhuojunjian commented on SOLR-4698: --- no one can provide any idea? > "java.lang.OutOfMemoryError: Map failed" when run in JRE64 > > > Key: SOLR-4698 > URL: https://issues.apache.org/jira/browse/SOLR-4698 > Project: Solr > Issue Type: Bug > Components: scripts and tools >Affects Versions: 4.0 > Environment: CPU:4 cores > Memory:64G > Hard Disk:2.5T > OS:linux >Reporter: zhuojunjian > Fix For: 4.3 > > > we make solr run in tomcat. and now there are 10 million records desployed > averagely in solrcloud which has 3 shards. each record's size is about 1.5k. > first we used JRE32. then we found it was not fast enough when the current > search request count reached 300. > so we think maybe the memory assigned for solr is not enough. and we replace > JRE32 with JRE64, and set "JAVA_OPTS="-Xms2048m -Xmx5120m"" in > $TOMCAT_HOME/bin/catalina.sh. but when we restart the solrcloud, we find it > failed. the error log is below: > 2013-04-10 18:58:36,174 INFO org.apache.solr.core.SolrCore:847 - [metadata] > CLOSING SolrCore org.apache.solr.core.SolrCore@74a638fc > 2013-04-10 18:58:36,177 INFO org.apache.solr.core.SolrCore:1658 - [metadata] > Closing main searcher on request. > 2013-04-10 18:58:36,178 ERROR org.apache.solr.core.CoreContainer:875 - Unable > to create core: metadata > org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.(SolrCore.java:721) > at org.apache.solr.core.SolrCore.(SolrCore.java:566) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:850) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:534) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:356) > at > org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:308) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:107) > at > org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:277) > at > org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:258) > at > org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:382) > at > org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:103) > at > org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4650) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5306) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1114) > at > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1673) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1310) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1422) > at org.apache.solr.core.SolrCore.(SolrCore.java:696) > ... 24 more > Caused by: java.io.IOException: Map failed > at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:748) > at org.apache.lucene.store.MMapDirectory.map(MMapDirectory.java:284) > at > org.apache.lucene.store.MMapDirectory$MMapIndexInput.(MMapDirectory.java:256) > at > org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:224) > at > org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:232) > at > org.apache.lucene.codecs.lucene40.Lucene40PostingsReader.(Lucene40PostingsR
[jira] [Created] (SOLR-4698) "java.lang.OutOfMemoryError: Map failed" when run in JRE64
zhuojunjian created SOLR-4698: - Summary: "java.lang.OutOfMemoryError: Map failed" when run in JRE64 Key: SOLR-4698 URL: https://issues.apache.org/jira/browse/SOLR-4698 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.0 Environment: CPU:4 cores Memory:64G Hard Disk:2.5T OS:linux Reporter: zhuojunjian Fix For: 4.3 we make solr run in tomcat. and now there are 10 million records desployed averagely in solrcloud which has 3 shards. each record's size is about 1.5k. first we used JRE32. then we found it was not fast enough when the current search request count reached 300. so we think maybe the memory assigned for solr is not enough. and we replace JRE32 with JRE64, and set "JAVA_OPTS="-Xms2048m -Xmx5120m"" in $TOMCAT_HOME/bin/catalina.sh. but when we restart the solrcloud, we find it failed. the error log is below: 2013-04-10 18:58:36,174 INFO org.apache.solr.core.SolrCore:847 - [metadata] CLOSING SolrCore org.apache.solr.core.SolrCore@74a638fc 2013-04-10 18:58:36,177 INFO org.apache.solr.core.SolrCore:1658 - [metadata] Closing main searcher on request. 2013-04-10 18:58:36,178 ERROR org.apache.solr.core.CoreContainer:875 - Unable to create core: metadata org.apache.solr.common.SolrException: Error opening new searcher at org.apache.solr.core.SolrCore.(SolrCore.java:721) at org.apache.solr.core.SolrCore.(SolrCore.java:566) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:850) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:534) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:356) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:308) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:107) at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:277) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:258) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:382) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:103) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4650) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5306) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1114) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1673) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.solr.common.SolrException: Error opening new searcher at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1310) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1422) at org.apache.solr.core.SolrCore.(SolrCore.java:696) ... 24 more Caused by: java.io.IOException: Map failed at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:748) at org.apache.lucene.store.MMapDirectory.map(MMapDirectory.java:284) at org.apache.lucene.store.MMapDirectory$MMapIndexInput.(MMapDirectory.java:256) at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:224) at org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:232) at org.apache.lucene.codecs.lucene40.Lucene40PostingsReader.(Lucene40PostingsReader.java:68) at org.apache.lucene.codecs.lucene40.Lucene40PostingsFormat.fieldsProducer(Lucene40PostingsFormat.java:316) at org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:194) at org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:233) at org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders
[jira] [Commented] (SOLR-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596952#comment-13596952 ] zhuojunjian commented on SOLR-4506: --- hi ok. do you think when the version 4.3 will be released? > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian >Assignee: Mark Miller > Fix For: 4.0, 4.3 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592075#comment-13592075 ] zhuojunjian commented on SOLR-4506: --- hi do you have any plan for this issue ? 4.1 or other ? > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591978#comment-13591978 ] zhuojunjian commented on SOLR-4506: --- thanks for your reply. > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591953#comment-13591953 ] zhuojunjian commented on SOLR-4506: --- OK I got that. > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590369#comment-13590369 ] zhuojunjian commented on SOLR-4506: --- hi we have duplicated the issue today. step 1: kill one replicate node (node A) , and make it not running. step 2: import many data to the solrcloud so that its leader node created too many new indexes. step 3: make node A running normally, and it will download files from its leader node. step 4: before node A finishes the download operation, kill node A again. step 5: then make node A running normally again, we will find there are two index dirs in the ../data/., and if we continue step 3 ~ step 4 , the number of index dirs will increase . I think it may be a bug. do you have any idea about that? > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588100#comment-13588100 ] zhuojunjian commented on SOLR-4506: --- I checked the solr JIRA list and find some similar issues. you can see SOLR-3853.because we missed the log files, so we can not check what case will cause the issue. And I am trying to duplicate the issue. > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-3853) Solr Replication does not delete temp index folder in case of broken master index
[ https://issues.apache.org/jira/browse/SOLR-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588094#comment-13588094 ] zhuojunjian commented on SOLR-3853: --- any idea about this issue? I met an issue(see SOLR-4506 ) like this issue. because we missed the log files, so we can not check what case will cause the issue. and I am trying to duplicate the issue. > Solr Replication does not delete temp index folder in case of broken master > index > - > > Key: SOLR-3853 > URL: https://issues.apache.org/jira/browse/SOLR-3853 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 3.6.1 > Environment: 2 CentOS Linux Servers >Reporter: Robert Benak >Priority: Minor > > We have a master/slave solr setup. We did some fail over tests with solr > regarding replication. We corrupted the master index ( we deleted files ) > during runtime. During the next replication of the slave it trasfered the > broken index from the master server and during that we got an fileNotFound > Exception which stopped the replication. So the slave index was not > overwritted and still working. But there is still a temp folder on the disk ( > like /data/index.xx/ ). This happened after every replication > until the disk was full. So a lot of temp folders was created. -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[ https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587874#comment-13587874 ] zhuojunjian commented on SOLR-4506: --- hi thanks for your reply :) now what we can do ? upgrade solr4.0 to solr4.1 or waiting? Some more specific questions: 1.in what case indexes such as index.{date} are created ? 2.is it configurable to clean up useless index.{date} in solr4.0 ? > [solr4.0.0] many index.{date} dir in replication node > -- > > Key: SOLR-4506 > URL: https://issues.apache.org/jira/browse/SOLR-4506 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: the solr4.0 runs on suse11. > mem:32G > cpu:16 cores >Reporter: zhuojunjian > Fix For: 4.0 > > Original Estimate: 12h > Remaining Estimate: 12h > > in our test,we used solrcloud feature in solr4.0(version detail > :4.0.0.2012.10.06.03.04.33). > the solrcloud configuration is 3 shards and 2 replications each shard. > we found that there are over than 25 dirs which named index.{date} in one > replication node belonging to shard 3. > for example: > index.2013021725864 index.20130218012211880 index.20130218015714713 > index.20130218023101958 index.20130218030424083 tlog > index.20130218005648324 index.20130218012751078 index.20130218020141293 > the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. > so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? > what can I do? -- 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-1781) Replication index directories not always cleaned up
[ https://issues.apache.org/jira/browse/SOLR-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586918#comment-13586918 ] zhuojunjian commented on SOLR-1781: --- hi sure this issue is fixed in solr4.0 ? we find the issue in solr4.0 in our enviroment . I have created a new JIRA "SOLR-4506". > Replication index directories not always cleaned up > --- > > Key: SOLR-1781 > URL: https://issues.apache.org/jira/browse/SOLR-1781 > Project: Solr > Issue Type: Bug > Components: replication (java), SolrCloud >Affects Versions: 1.4 > Environment: Windows Server 2003 R2, Java 6b18 >Reporter: Terje Sten Bjerkseth >Assignee: Mark Miller > Fix For: 4.0-BETA, 5.0 > > Attachments: > 0001-Replication-does-not-always-clean-up-old-directories.patch, > SOLR-1781.patch, SOLR-1781.patch > > > We had the same problem as someone described in > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201001.mbox/%3c222a518d-ddf5-4fc8-a02a-74d4f232b...@snooth.com%3e. > A partial copy of that message: > We're using the new replication and it's working pretty well. There's > one detail I'd like to get some more information about. > As the replication works, it creates versions of the index in the data > directory. Originally we had index/, but now there are dated versions > such as index.20100127044500/, which are the replicated versions. > Each copy is sized in the vicinity of 65G. With our current hard drive > it's fine to have two around, but 3 gets a little dicey. Sometimes > we're finding that the replication doesn't always clean up after > itself. I would like to understand this better, or to not have this > happen. It could be a configuration issue. -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
zhuojunjian created SOLR-4506: - Summary: [solr4.0.0] many index.{date} dir in replication node Key: SOLR-4506 URL: https://issues.apache.org/jira/browse/SOLR-4506 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: the solr4.0 runs on suse11. mem:32G cpu:16 cores Reporter: zhuojunjian Fix For: 4.0 in our test,we used solrcloud feature in solr4.0(version detail :4.0.0.2012.10.06.03.04.33). the solrcloud configuration is 3 shards and 2 replications each shard. we found that there are over than 25 dirs which named index.{date} in one replication node belonging to shard 3. for example: index.2013021725864 index.20130218012211880 index.20130218015714713 index.20130218023101958 index.20130218030424083 tlog index.20130218005648324 index.20130218012751078 index.20130218020141293 the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0. so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ? what can I do? -- 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