You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/02/24 11:58:18 UTC
[jira] [Commented] (SOLR-8727) Limit Threadpools by default
[ https://issues.apache.org/jira/browse/SOLR-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15162809#comment-15162809 ]
ASF GitHub Bot commented on SOLR-8727:
--------------------------------------
GitHub user bjoernhaeuser opened a pull request:
https://github.com/apache/lucene-solr/pull/11
Limit threadpools by default to 128
Integer.MAX_VALUE could kill the VM instead of providing useful error
messages.
128 is a wild guess by myself. Let's discuss a good default value for
this :)
Jira: https://issues.apache.org/jira/browse/SOLR-8727
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rebuy-de/lucene-solr limit-threadpools
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
----
commit cff552d1dc4e7bc7892d9521355c651c2ed2ad06
Author: Björn Häuser <b....@rebuy.de>
Date: 2016-02-24T10:44:09Z
Limit threadpools by default to 128
Integer.MAX_VALUE could kill the VM instead of providing useful error
messages.
128 is a wild guess by myself. Let's discuss a good default value for
this :)
----
> 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
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org