[jira] [Updated] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3
[ https://issues.apache.org/jira/browse/SOLR-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Fortino updated SOLR-10150: Priority: Critical (was: Major) > Solr 6.4 up to 10x slower than 6.3 > -- > > Key: SOLR-10150 > URL: https://issues.apache.org/jira/browse/SOLR-10150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Fabrizio Fortino >Priority: Critical > Labels: performance > Attachments: Screen Shot 2017-02-16 at 17.31.02.png > > > We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 > and huge increase of CPU utilization. Our use case is pretty simple: we have > a single Solr Core with around 600K small size documents. We just do lookups > by key (no full text searches) and use faceting capabilities. > Using the Solr Admin Thread Dump utilities we noticed a lot of threads using > considerable cpuTime / userTime on codehale metrics (snapshot attached). The > metrics part has been drastically changed in 6.4 > (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 > has solved our performance problems. > Is there any way to disable these metrics in version 6.4 ? > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3
[ https://issues.apache.org/jira/browse/SOLR-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Fortino updated SOLR-10150: Attachment: Screen Shot 2017-02-16 at 17.31.02.png > Solr 6.4 up to 10x slower than 6.3 > -- > > Key: SOLR-10150 > URL: https://issues.apache.org/jira/browse/SOLR-10150 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Fabrizio Fortino > Labels: performance > Attachments: Screen Shot 2017-02-16 at 17.31.02.png > > > We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 > and huge increase of CPU utilization. Our use case is pretty simple: we have > a single Solr Core with around 600K small size documents. We just do lookups > by key (no full text searches) and use faceting capabilities. > Using the Solr Admin Thread Dump utilities we noticed a lot of threads using > considerable cpuTime / userTime on codehale metrics (snapshot attached). The > metrics part has been drastically changed in 6.4 > (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 > has solved our performance problems. > Is there any way to disable these metrics in version 6.4 ? > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10150) Solr 6.4 up to 10x slower than 6.3
Fabrizio Fortino created SOLR-10150: --- Summary: Solr 6.4 up to 10x slower than 6.3 Key: SOLR-10150 URL: https://issues.apache.org/jira/browse/SOLR-10150 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Fabrizio Fortino We noticed a considerable performance degradation (5x to 10x) using Solr 6.4 and huge increase of CPU utilization. Our use case is pretty simple: we have a single Solr Core with around 600K small size documents. We just do lookups by key (no full text searches) and use faceting capabilities. Using the Solr Admin Thread Dump utilities we noticed a lot of threads using considerable cpuTime / userTime on codehale metrics (snapshot attached). The metrics part has been drastically changed in 6.4 (https://issues.apache.org/jira/browse/SOLR-4735). Rolling back to Solr 6.3 has solved our performance problems. Is there any way to disable these metrics in version 6.4 ? Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9208) ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption
[ https://issues.apache.org/jira/browse/SOLR-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382026#comment-15382026 ] Fabrizio Fortino commented on SOLR-9208: [~mkhludnev] Thanks for replying back to me. But I am not agree about the fact that this is not an issue. If using the solr java API causes this kind of problems I think it's an issue that should be addressed. Another explanation could be that I am using the API in a bad way. So far I haven't had any hint about it though. > ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU > consumption > - > > Key: SOLR-9208 > URL: https://issues.apache.org/jira/browse/SOLR-9208 > Project: Solr > Issue Type: Bug > Components: multicore, Server >Affects Versions: 6.0 >Reporter: Fabrizio Fortino >Assignee: Mikhail Khludnev > > In our use case we swap two cores and close the old one. We started seeing > the below error from time to time (it's completely random, we are unable to > reproduce it). Moreover we have noticed that when this Exception is thrown > the CPU consumption goes pretty high (80-100%). > Error Message: > java.util.ConcurrentModificationException: > java.util.ConcurrentModificationException > StackTrace: > java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901) > java.util.ArrayList$Itr.next (ArrayList.java:851) > org.apache.solr.core.SolrCore.close (SolrCore.java:1134) > org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513) > org.apache.solr.servlet.SolrDispatchFilter.doFilter > (SolrDispatchFilter.java:242) > org.apache.solr.servlet.SolrDispatchFilter.doFilter > (SolrDispatchFilter.java:184) > …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) > org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581) > org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143) > org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548) > …g.eclipse.jetty.server.session.SessionHandler.doHandle > (SessionHandler.java:226) > …g.eclipse.jetty.server.handler.ContextHandler.doHandle > (ContextHandler.java:1160) > org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511) > org.eclipse.jetty.server.session.SessionHandler.doScope > (SessionHandler.java:185) > org.eclipse.jetty.server.handler.ContextHandler.doScope > (ContextHandler.java:1092) > org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141) > …e.jetty.server.handler.ContextHandlerCollection.handle > (ContextHandlerCollection.java:213) > ….eclipse.jetty.server.handler.HandlerCollection.handle > (HandlerCollection.java:119) > org.eclipse.jetty.server.handler.HandlerWrapper.handle > (HandlerWrapper.java:134) > org.eclipse.jetty.server.Server.handle (Server.java:518) > org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308) > org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244) > …pse.jetty.io.AbstractConnection$ReadCallback.succeeded > (AbstractConnection.java:273) > org.eclipse.jetty.io.FillInterest.fillable (FillInterest.java:95) > org.eclipse.jetty.io.SelectChannelEndPoint$2.run > (SelectChannelEndPoint.java:93) > …il.thread.strategy.ExecuteProduceConsume.produceAndRun > (ExecuteProduceConsume.java:246) > …e.jetty.util.thread.strategy.ExecuteProduceConsume.run > (ExecuteProduceConsume.java:156) > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob > (QueuedThreadPool.java:654) > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run > (QueuedThreadPool.java:572) > java.lang.Thread.run (Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9208) ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption
[
https://issues.apache.org/jira/browse/SOLR-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374718#comment-15374718
]
Fabrizio Fortino commented on SOLR-9208:
[~mkhludnev] I am pretty sure this can't happen.
Let me give some additional details of what I am trying to do.
I have created a Solr CoreAdminHandler extension with the goal to swap two
cores and remove the old one.
My code looks like this:
{code:java}
SolrCore core = coreContainer.create("newcore", coreProps)
coreContainer.swap("newcore", "livecore")
// the old livecore is now newcore, so unload it and remove all the related dirs
coreContainer.unload("newcore", true, true, true)
{code}
This unfortunately does not work. I have opened an issue but I got no answers
so far (details here https://issues.apache.org/jira/browse/SOLR-8757).
As a workaround, I am "manually" closing the references to the core I want to
unload before unloading it. The code now looks like:
{code:java}
SolrCore core = coreContainer.create("newcore", coreProps)
coreContainer.swap("newcore", "livecore")
// the old livecore is now newcore, so unload it and remove all the related dirs
SolrCore oldCore = coreContainer.getCore("newCore")
while (oldCore.getOpenCount > 1) {
oldCore.close()
}
coreContainer.unload("newcore", true, true, true)
{code}
> ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU
> consumption
> -
>
> Key: SOLR-9208
> URL: https://issues.apache.org/jira/browse/SOLR-9208
> Project: Solr
> Issue Type: Bug
> Components: multicore, Server
>Affects Versions: 6.0
>Reporter: Fabrizio Fortino
>Assignee: Mikhail Khludnev
>
> In our use case we swap two cores and close the old one. We started seeing
> the below error from time to time (it's completely random, we are unable to
> reproduce it). Moreover we have noticed that when this Exception is thrown
> the CPU consumption goes pretty high (80-100%).
> Error Message:
> java.util.ConcurrentModificationException:
> java.util.ConcurrentModificationException
> StackTrace:
> java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901)
> java.util.ArrayList$Itr.next (ArrayList.java:851)
> org.apache.solr.core.SolrCore.close (SolrCore.java:1134)
> org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter
> (SolrDispatchFilter.java:242)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter
> (SolrDispatchFilter.java:184)
> …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143)
> org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548)
> …g.eclipse.jetty.server.session.SessionHandler.doHandle
> (SessionHandler.java:226)
> …g.eclipse.jetty.server.handler.ContextHandler.doHandle
> (ContextHandler.java:1160)
> org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511)
> org.eclipse.jetty.server.session.SessionHandler.doScope
> (SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope
> (ContextHandler.java:1092)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141)
> …e.jetty.server.handler.ContextHandlerCollection.handle
> (ContextHandlerCollection.java:213)
> ….eclipse.jetty.server.handler.HandlerCollection.handle
> (HandlerCollection.java:119)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle
> (HandlerWrapper.java:134)
> org.eclipse.jetty.server.Server.handle (Server.java:518)
> org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308)
> org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244)
> …pse.jetty.io.AbstractConnection$ReadCallback.succeeded
> (AbstractConnection.java:273)
> org.eclipse.jetty.io.FillInterest.fillable (FillInterest.java:95)
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run
> (SelectChannelEndPoint.java:93)
> …il.thread.strategy.ExecuteProduceConsume.produceAndRun
> (ExecuteProduceConsume.java:246)
> …e.jetty.util.thread.strategy.ExecuteProduceConsume.run
> (ExecuteProduceConsume.java:156)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob
> (QueuedThreadPool.java:654)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run
> (QueuedThreadPool.java:572)
> java.lang.Thread.run (Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9208) ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption
[ https://issues.apache.org/jira/browse/SOLR-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360653#comment-15360653 ] Fabrizio Fortino commented on SOLR-9208: [~mkhludnev] yes. The exception is thrown when I try to unload the core from CoreAdminHandler. > ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU > consumption > - > > Key: SOLR-9208 > URL: https://issues.apache.org/jira/browse/SOLR-9208 > Project: Solr > Issue Type: Bug > Components: multicore, Server >Affects Versions: 6.0 >Reporter: Fabrizio Fortino > > In our use case we swap two cores and close the old one. We started seeing > the below error from time to time (it's completely random, we are unable to > reproduce it). Moreover we have noticed that when this Exception is thrown > the CPU consumption goes pretty high (80-100%). > Error Message: > java.util.ConcurrentModificationException: > java.util.ConcurrentModificationException > StackTrace: > java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901) > java.util.ArrayList$Itr.next (ArrayList.java:851) > org.apache.solr.core.SolrCore.close (SolrCore.java:1134) > org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513) > org.apache.solr.servlet.SolrDispatchFilter.doFilter > (SolrDispatchFilter.java:242) > org.apache.solr.servlet.SolrDispatchFilter.doFilter > (SolrDispatchFilter.java:184) > …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) > org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581) > org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143) > org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548) > …g.eclipse.jetty.server.session.SessionHandler.doHandle > (SessionHandler.java:226) > …g.eclipse.jetty.server.handler.ContextHandler.doHandle > (ContextHandler.java:1160) > org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511) > org.eclipse.jetty.server.session.SessionHandler.doScope > (SessionHandler.java:185) > org.eclipse.jetty.server.handler.ContextHandler.doScope > (ContextHandler.java:1092) > org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141) > …e.jetty.server.handler.ContextHandlerCollection.handle > (ContextHandlerCollection.java:213) > ….eclipse.jetty.server.handler.HandlerCollection.handle > (HandlerCollection.java:119) > org.eclipse.jetty.server.handler.HandlerWrapper.handle > (HandlerWrapper.java:134) > org.eclipse.jetty.server.Server.handle (Server.java:518) > org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308) > org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244) > …pse.jetty.io.AbstractConnection$ReadCallback.succeeded > (AbstractConnection.java:273) > org.eclipse.jetty.io.FillInterest.fillable (FillInterest.java:95) > org.eclipse.jetty.io.SelectChannelEndPoint$2.run > (SelectChannelEndPoint.java:93) > …il.thread.strategy.ExecuteProduceConsume.produceAndRun > (ExecuteProduceConsume.java:246) > …e.jetty.util.thread.strategy.ExecuteProduceConsume.run > (ExecuteProduceConsume.java:156) > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob > (QueuedThreadPool.java:654) > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run > (QueuedThreadPool.java:572) > java.lang.Thread.run (Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9208) ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption
[ https://issues.apache.org/jira/browse/SOLR-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Fortino updated SOLR-9208: --- Description: In our use case we swap two cores and close the old one. We started seeing the below error from time to time (it's completely random, we are unable to reproduce it). Moreover we have noticed that when this Exception is thrown the CPU consumption goes pretty high (80-100%). Error Message: java.util.ConcurrentModificationException: java.util.ConcurrentModificationException StackTrace: java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901) java.util.ArrayList$Itr.next (ArrayList.java:851) org.apache.solr.core.SolrCore.close (SolrCore.java:1134) org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:242) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:184) …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143) org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548) …g.eclipse.jetty.server.session.SessionHandler.doHandle (SessionHandler.java:226) …g.eclipse.jetty.server.handler.ContextHandler.doHandle (ContextHandler.java:1160) org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511) org.eclipse.jetty.server.session.SessionHandler.doScope (SessionHandler.java:185) org.eclipse.jetty.server.handler.ContextHandler.doScope (ContextHandler.java:1092) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141) …e.jetty.server.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:213) ….eclipse.jetty.server.handler.HandlerCollection.handle (HandlerCollection.java:119) org.eclipse.jetty.server.handler.HandlerWrapper.handle (HandlerWrapper.java:134) org.eclipse.jetty.server.Server.handle (Server.java:518) org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308) org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244) …pse.jetty.io.AbstractConnection$ReadCallback.succeeded (AbstractConnection.java:273) org.eclipse.jetty.io.FillInterest.fillable (FillInterest.java:95) org.eclipse.jetty.io.SelectChannelEndPoint$2.run (SelectChannelEndPoint.java:93) …il.thread.strategy.ExecuteProduceConsume.produceAndRun (ExecuteProduceConsume.java:246) …e.jetty.util.thread.strategy.ExecuteProduceConsume.run (ExecuteProduceConsume.java:156) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:654) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:572) java.lang.Thread.run (Thread.java:745) was: In out use case we swap two cores and close the old one. We started seeing the below error from time to time (it's completely random, we are unable to reproduce it). Moreover we have noticed that when this Exception is thrown the CPU consumption goes pretty high (80-100%). Error Message: java.util.ConcurrentModificationException: java.util.ConcurrentModificationException StackTrace: java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901) java.util.ArrayList$Itr.next (ArrayList.java:851) org.apache.solr.core.SolrCore.close (SolrCore.java:1134) org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:242) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:184) …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143) org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548) …g.eclipse.jetty.server.session.SessionHandler.doHandle (SessionHandler.java:226) …g.eclipse.jetty.server.handler.ContextHandler.doHandle (ContextHandler.java:1160) org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511) org.eclipse.jetty.server.session.SessionHandler.doScope (SessionHandler.java:185) org.eclipse.jetty.server.handler.ContextHandler.doScope (ContextHandler.java:1092) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141) …e.jetty.server.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:213) ….eclipse.jetty.server.handler.HandlerCollection.handle (HandlerCollection.java:119) org.eclipse.jetty.server.handler.HandlerWrapper.handle (HandlerWrapper.java:134) org.eclipse.jetty.server.Server.handle (Server.java:518) org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308) org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244)
[jira] [Created] (SOLR-9208) ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption
Fabrizio Fortino created SOLR-9208: -- Summary: ConcurrentModificationException on SolrCore.close() resulting in abnormal CPU consumption Key: SOLR-9208 URL: https://issues.apache.org/jira/browse/SOLR-9208 Project: Solr Issue Type: Bug Components: multicore, Server Affects Versions: 6.0 Reporter: Fabrizio Fortino In out use case we swap two cores and close the old one. We started seeing the below error from time to time (it's completely random, we are unable to reproduce it). Moreover we have noticed that when this Exception is thrown the CPU consumption goes pretty high (80-100%). Error Message: java.util.ConcurrentModificationException: java.util.ConcurrentModificationException StackTrace: java.util.ArrayList$Itr.checkForComodification (ArrayList.java:901) java.util.ArrayList$Itr.next (ArrayList.java:851) org.apache.solr.core.SolrCore.close (SolrCore.java:1134) org.apache.solr.servlet.HttpSolrCall.destroy (HttpSolrCall.java:513) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:242) org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:184) …ipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:581) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143) org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:548) …g.eclipse.jetty.server.session.SessionHandler.doHandle (SessionHandler.java:226) …g.eclipse.jetty.server.handler.ContextHandler.doHandle (ContextHandler.java:1160) org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:511) org.eclipse.jetty.server.session.SessionHandler.doScope (SessionHandler.java:185) org.eclipse.jetty.server.handler.ContextHandler.doScope (ContextHandler.java:1092) org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141) …e.jetty.server.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:213) ….eclipse.jetty.server.handler.HandlerCollection.handle (HandlerCollection.java:119) org.eclipse.jetty.server.handler.HandlerWrapper.handle (HandlerWrapper.java:134) org.eclipse.jetty.server.Server.handle (Server.java:518) org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:308) org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:244) …pse.jetty.io.AbstractConnection$ReadCallback.succeeded (AbstractConnection.java:273) org.eclipse.jetty.io.FillInterest.fillable (FillInterest.java:95) org.eclipse.jetty.io.SelectChannelEndPoint$2.run (SelectChannelEndPoint.java:93) …il.thread.strategy.ExecuteProduceConsume.produceAndRun (ExecuteProduceConsume.java:246) …e.jetty.util.thread.strategy.ExecuteProduceConsume.run (ExecuteProduceConsume.java:156) org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:654) org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:572) java.lang.Thread.run (Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8757) Swap + unload does not work
Fabrizio Fortino created SOLR-8757:
--
Summary: Swap + unload does not work
Key: SOLR-8757
URL: https://issues.apache.org/jira/browse/SOLR-8757
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 5.5
Reporter: Fabrizio Fortino
I have created a Solr CoreAdminHandler extension with the goal to swap two
cores and remove the old one.
My code looks like this:
SolrCore core = coreContainer.create("newcore", coreProps)
coreContainer.swap("newcore", "livecore")
// the old livecore is now newcore, so unload it and remove all the related dirs
coreContainer.unload("newcore", true, true, true)
After the last statement get executed the Solr log starts printing the
following messages forever
61424 INFO (pool-1-thread-1) [ x:newcore] o.a.s.c.SolrCore Core newcore is not
yet closed, waiting 100 ms before checking again.
I tried to call the close() method on the SolrCore instance before and after
the unload but the result is the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
