[ https://issues.apache.org/jira/browse/SOLR-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163047#comment-15163047 ]
Björn Häuser commented on SOLR-8727: ------------------------------------ Well, I was never aware of a problem of distributed locks in solr. So I was just aiming at the smallest possible fix to ensure that there are no threadpools which dont have a limit. After reading the linked issue I can see the problem which is imposed by limiting the threadpools. But I also would say that consuming as much threads as possible from the OS is also not good user behaviour. In this scenario (with the linked stack trace) I am not able to see the underlying problem. Sure, most of the threadpools can be limited through configuration :) Should we close this issue here and rather solve 7344? > Limit Threadpools by default > ---------------------------- > > Key: SOLR-8727 > URL: https://issues.apache.org/jira/browse/SOLR-8727 > Project: Solr > Issue Type: Improvement > Components: SolrJ > Affects Versions: 5.2.1 > Reporter: Björn Häuser > Assignee: Noble Paul > > Yesterday we had a problem in our prodution cluster, it was running out of > native threads: > {code} > null:java.lang.RuntimeException: java.lang.OutOfMemoryError: unable to create > new native thread > at org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:593) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:497) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.OutOfMemoryError: unable to create new native thread > at java.lang.Thread.start0(Native Method) > at java.lang.Thread.start(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.addWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source) > at > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.execute(ExecutorUtil.java:135) > at java.util.concurrent.ExecutorCompletionService.submit(Unknown Source) > at > org.apache.solr.handler.component.HttpShardHandler.submit(HttpShardHandler.java:250) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:352) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) > ... 22 more > {code} > After digging a little bit through the source code I found several > ThreadPools which a default maxCoreSize of Integer.MAX_VALUE. I think we > should figure out a better default then this. > Going to create the corresponding pull reuquest on github for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org