[JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1530:
-------------------------------------
It's worth noting though that unless you have very long running operations, a lower thread count might be acceptable for WildFly with Undertow because its task dispatch model is fundamentally different.
> It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1530
> URL: https://issues.jboss.org/browse/WFCORE-1530
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.1.0.Final
> Reporter: Juan AMAT
> Assignee: Tomaz Cerar
>
> We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly.
> While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly.
> Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count.
> We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers).
> It will be nicer to be able to configure instead a per-cpu value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1530:
-------------------------------------
We had this and then it was requested to be removed as too confusing or something. I guess I don't really care either way.
> It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1530
> URL: https://issues.jboss.org/browse/WFCORE-1530
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.1.0.Final
> Reporter: Juan AMAT
> Assignee: Tomaz Cerar
>
> We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly.
> While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly.
> Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count.
> We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers).
> It will be nicer to be able to configure instead a per-cpu value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1530:
-----------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
> It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1530
> URL: https://issues.jboss.org/browse/WFCORE-1530
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.1.0.Final
> Reporter: Juan AMAT
> Assignee: Tomaz Cerar
>
> We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly.
> While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly.
> Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count.
> We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers).
> It will be nicer to be able to configure instead a per-cpu value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1530:
-------------------------------------
[~dmlloyd] wdyt about this?
> It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1530
> URL: https://issues.jboss.org/browse/WFCORE-1530
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.1.0.Final
> Reporter: Juan AMAT
> Assignee: Tomaz Cerar
>
> We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly.
> While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly.
> Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count.
> We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers).
> It will be nicer to be able to configure instead a per-cpu value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-4693) Slow HTTPS Upload provokes High CPU Load
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4693?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-4693.
-------------------------------
Fix Version/s: 10.0.0.Final
Resolution: Done
> Slow HTTPS Upload provokes High CPU Load
> ----------------------------------------
>
> Key: WFLY-4693
> URL: https://issues.jboss.org/browse/WFLY-4693
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 9.0.0.CR1
> Reporter: Serge Mürset
> Assignee: David Lloyd
> Labels: undertow, web
> Fix For: 10.0.0.Final
>
>
> This issue is a reopen of https://issues.jboss.org/browse/UNDERTOW-345.
> This Issue is not fixed with Wildfly 9.0 CR1 when using the standard config without any timeouts set (however, above mentioned ticket indicates issue was fixed in Undertow 1.2.0.Beta6).
> This is a major bug, as just one client with bad connectivity will cause a 100% CPU Load on Wildfly whilst the HTTPS upload is being read. It's also a real-world bug, as every note-worthy productive server will have at least one client with bad connectivity at any given time. Duration of the high CPU load directly correlates to the duration it takes the client to send all his POST data.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-5968) NPE in HttpResponseConduit
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5968?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-5968.
-------------------------------
Fix Version/s: 10.0.0.Final
Assignee: Stuart Douglas (was: Jason Greene)
Resolution: Done
> NPE in HttpResponseConduit
> --------------------------
>
> Key: WFLY-5968
> URL: https://issues.jboss.org/browse/WFLY-5968
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: FreeBSD10.2+Wildfly10.0.0.CR5
> Reporter: huanghwh
> Assignee: Stuart Douglas
> Fix For: 10.0.0.Final
>
>
> I got this problem:
> 2016-01-10 11:19:06,026 INFO [cn.org.gddsn.sss.server.SSSSessionListener] (default task-65) Session Id YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u created.
> 2016-01-10 11:19:06,029 INFO [cn.org.gddsn.sss.server.SSSResourceImpl] (default task-65) User jeew(127.0.0.1:57300) login in session YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u.
> 2016-01-10 11:19:06,046 INFO [cn.org.gddsn.sss.server.MiniSeedSender] (default task-66) Send Mini Seed Queue size: 64
> 2016-01-10 11:19:06,047 INFO [cn.org.gddsn.sss.server.MiniSeedSender] (default task-66) MiniSeedSender for jeew starting...
> 2016-01-10 11:21:20,989 INFO [cn.org.gddsn.sss.server.SSSSessionListener] (default task-96) Session Id lO2XhoMjwGlgDWXqGynGFX4WiP_b6OERlvFO-8wS created.
> 2016-01-10 11:21:28,909 ERROR [io.undertow.request] (default task-66) UT005023: Exception handling request to /jopens-sss/sss/retr;staList=%20GD%2FPA01;chanMask=0x7fffffff;sn=-1: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:167)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:638)
> at io.undertow.conduits.ChunkedStreamSinkConduit.doWrite(ChunkedStreamSinkConduit.java:163)
> at io.undertow.conduits.ChunkedStreamSinkConduit.write(ChunkedStreamSinkConduit.java:127)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2000)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:567)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.flushInternal(ServletOutputStreamImpl.java:482)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:469)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.flush(HttpServletResponseWrapper.java:52)
> at org.jboss.resteasy.util.CommitHeaderOutputStream.flush(CommitHeaderOutputStream.java:78)
> at cn.org.gddsn.sss.server.MiniSeedSender.run(MiniSeedSender.java:84)
> at cn.org.gddsn.sss.server.SSSResourceImpl$1.write(SSSResourceImpl.java:182)
> at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:32)
> at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:17)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
> at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
> at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:145)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
> ... 33 more
> 2016-01-10 11:21:28,912 ERROR [io.undertow.request] (default task-66) UT005071: Undertow request failed HttpServerExchange{ GET /jopens-sss/sss/retr;staList=%20GD%2FPA01;chanMask=0x7fffffff;sn=-1 request {Accept=[text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2], Connection=[keep-alive], Cookie=[JSESSIONID=YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u.mbp], User-Agent=[Java/1.8.0_66], Host=[127.0.0.1:8080]} response {Connection=[keep-alive], X-Powered-By=[Undertow/1], Server=[WildFly/10], Transfer-Encoding=[chunked], Content-Type=[application/octet-stream], Date=[Sun, 10 Jan 2016 03:19:15 GMT]}}: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.truncateWrites(HttpResponseConduit.java:739)
> at io.undertow.conduits.ChunkedStreamSinkConduit.terminateWrites(ChunkedStreamSinkConduit.java:302)
> at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178)
> at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:608)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:476)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2016-01-10 11:21:28,920 ERROR [stderr] (default task-66) Exception in thread "default task-66" java.lang.NullPointerException
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:605)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:267)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:226)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.lang.Thread.run(Thread.java:745)
> Not seen in wildfly-9.0.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-5968) NPE in HttpResponseConduit
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5968?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5968:
------------------------------
Component/s: Web (Undertow)
(was: IO)
> NPE in HttpResponseConduit
> --------------------------
>
> Key: WFLY-5968
> URL: https://issues.jboss.org/browse/WFLY-5968
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: FreeBSD10.2+Wildfly10.0.0.CR5
> Reporter: huanghwh
> Assignee: Jason Greene
>
> I got this problem:
> 2016-01-10 11:19:06,026 INFO [cn.org.gddsn.sss.server.SSSSessionListener] (default task-65) Session Id YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u created.
> 2016-01-10 11:19:06,029 INFO [cn.org.gddsn.sss.server.SSSResourceImpl] (default task-65) User jeew(127.0.0.1:57300) login in session YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u.
> 2016-01-10 11:19:06,046 INFO [cn.org.gddsn.sss.server.MiniSeedSender] (default task-66) Send Mini Seed Queue size: 64
> 2016-01-10 11:19:06,047 INFO [cn.org.gddsn.sss.server.MiniSeedSender] (default task-66) MiniSeedSender for jeew starting...
> 2016-01-10 11:21:20,989 INFO [cn.org.gddsn.sss.server.SSSSessionListener] (default task-96) Session Id lO2XhoMjwGlgDWXqGynGFX4WiP_b6OERlvFO-8wS created.
> 2016-01-10 11:21:28,909 ERROR [io.undertow.request] (default task-66) UT005023: Exception handling request to /jopens-sss/sss/retr;staList=%20GD%2FPA01;chanMask=0x7fffffff;sn=-1: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:167)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:638)
> at io.undertow.conduits.ChunkedStreamSinkConduit.doWrite(ChunkedStreamSinkConduit.java:163)
> at io.undertow.conduits.ChunkedStreamSinkConduit.write(ChunkedStreamSinkConduit.java:127)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2000)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:567)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.flushInternal(ServletOutputStreamImpl.java:482)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:469)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.flush(HttpServletResponseWrapper.java:52)
> at org.jboss.resteasy.util.CommitHeaderOutputStream.flush(CommitHeaderOutputStream.java:78)
> at cn.org.gddsn.sss.server.MiniSeedSender.run(MiniSeedSender.java:84)
> at cn.org.gddsn.sss.server.SSSResourceImpl$1.write(SSSResourceImpl.java:182)
> at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:32)
> at org.jboss.resteasy.plugins.providers.StreamingOutputProvider.writeTo(StreamingOutputProvider.java:17)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
> at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
> at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:145)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
> at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
> ... 33 more
> 2016-01-10 11:21:28,912 ERROR [io.undertow.request] (default task-66) UT005071: Undertow request failed HttpServerExchange{ GET /jopens-sss/sss/retr;staList=%20GD%2FPA01;chanMask=0x7fffffff;sn=-1 request {Accept=[text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2], Connection=[keep-alive], Cookie=[JSESSIONID=YlASoaRZigqIVzOUMQB_nxeMl1eluerHurcbRG-u.mbp], User-Agent=[Java/1.8.0_66], Host=[127.0.0.1:8080]} response {Connection=[keep-alive], X-Powered-By=[Undertow/1], Server=[WildFly/10], Transfer-Encoding=[chunked], Content-Type=[application/octet-stream], Date=[Sun, 10 Jan 2016 03:19:15 GMT]}}: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.truncateWrites(HttpResponseConduit.java:739)
> at io.undertow.conduits.ChunkedStreamSinkConduit.terminateWrites(ChunkedStreamSinkConduit.java:302)
> at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178)
> at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:608)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:476)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2016-01-10 11:21:28,920 ERROR [stderr] (default task-66) Exception in thread "default task-66" java.lang.NullPointerException
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:605)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:267)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 2016-01-10 11:21:28,921 ERROR [stderr] (default task-66) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:226)
> 2016-01-10 11:21:28,922 ERROR [stderr] (default task-66) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2016-01-10 11:21:28,923 ERROR [stderr] (default task-66) at java.lang.Thread.run(Thread.java:745)
> Not seen in wildfly-9.0.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1530) It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1530?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-6466 to WFCORE-1530:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1530 (was: WFLY-6466)
Component/s: (was: IO)
Affects Version/s: 2.1.0.Final
(was: 10.0.0.Final)
> It should be possible to provide a 'per-cpu' value when configuring the task-max-threads attribute of a worker
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1530
> URL: https://issues.jboss.org/browse/WFCORE-1530
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.1.0.Final
> Reporter: Juan AMAT
> Assignee: Jason Greene
>
> We have an application running under JBoss EAP 6.4 and we are in the process to make it also run under Wildfly.
> While doing performance testing we noticed that the number of threads that can process the incoming http requests was way lower in Wildfly.
> Indeed we were using the 'default' worker and by default the max threads is set to 16 times the cpu count. In Jboss EAP the default configuration is 512 times the cpu count.
> We were hitting this max and we did increase it. But then we had to provide an absolute value (and we would need to provide different values per type of servers).
> It will be nicer to be able to configure instead a per-cpu value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months