[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)
9 years, 12 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)
9 years, 12 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)
9 years, 12 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)
9 years, 12 months
[JBoss JIRA] (WFCORE-1529) New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1529?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1529:
-------------------------------------
Description:
tl;dr version from Brian:
The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.
Original details from Rostislav:
I did quite simple thing in the loop :
* deploy attached application into jboss-eap-7.0/standalone/deployments/
* wait 1 minute
* remove anything from jboss-eap-7.0/standalone/deployments/
* wait 1 minute
I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
was:
I did quite simple thing in the loop :
* deploy attached application into jboss-eap-7.0/standalone/deployments/
* wait 1 minute
* remove anything from jboss-eap-7.0/standalone/deployments/
* wait 1 minute
I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
> New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1529
> URL: https://issues.jboss.org/browse/WFCORE-1529
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Rostislav Svoboda
> Assignee: Brian Stansberry
>
> tl;dr version from Brian:
> The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.
> Original details from Rostislav:
> I did quite simple thing in the loop :
> * deploy attached application into jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> * remove anything from jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
> After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
> Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
> Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
> Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1529) New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1529?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1529:
-------------------------------------
Priority: Minor (was: Major)
> New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1529
> URL: https://issues.jboss.org/browse/WFCORE-1529
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Rostislav Svoboda
> Assignee: Brian Stansberry
> Priority: Minor
>
> tl;dr version from Brian:
> The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.
> Original details from Rostislav:
> I did quite simple thing in the loop :
> * deploy attached application into jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> * remove anything from jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
> After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
> Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
> Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
> Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1529) New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1529?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-4546 to WFCORE-1529:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1529 (was: JBEAP-4546)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 2.1.0.Final
(was: 7.0.0.CR2)
> New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1529
> URL: https://issues.jboss.org/browse/WFCORE-1529
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Rostislav Svoboda
> Assignee: Brian Stansberry
>
> I did quite simple thing in the loop :
> * deploy attached application into jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> * remove anything from jboss-eap-7.0/standalone/deployments/
> * wait 1 minute
> I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
> After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
> Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... method addService
> Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ?
> Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1528) EAP 7 with secured management become unavailable after ~8 days
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1528?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1528:
------------------------------------------
I believe WFCORE-1428 is cause of WFCORE-1528, as it brings a non-fixed-size thread pool into Undertow's request handling, and Undertow's internal caching mechanisms are not designed for use with a non-fixed pool. As the pool churns threads, pooled ByteBuffers are not getting freed.
It's also better to use a fixed pool for the WFCORE-1428 work as this call path is for end-user requests and we want to limit concurrency of those a la what we do for native clients at https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j....
> EAP 7 with secured management become unavailable after ~8 days
> --------------------------------------------------------------
>
> Key: WFCORE-1528
> URL: https://issues.jboss.org/browse/WFCORE-1528
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.1.0.Final
> Environment: EAP 7.0.0.CR01 2-way ssl over remote https communication
> Reporter: Simeon Pinder
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Alpha1
>
>
> Appears there may be an EAP 7.0.0.CR01 2-way ssl issue in domain mode.
> Issue discovered by JON QE after testing for 8 days with SSL.
> JON QE did not see the same issue when running identical test against EAP 6.
> Restarting the remote client(JON Agent) did not repair/fix the issue, and only was repaired after EAP instance restarted.
> See BZ https://bugzilla.redhat.com/show_bug.cgi?id=1330180#c0 for more details.
> JON team would like some evaluation done to determine:
> i)if this is EAP 7 issue or
> ii)somehow just a JON issue
> iii)suggestions on what to do when we try to reproduce properly or ways to shorten reproduce cycle.
> This issue could affect GA release schedules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months