[JBoss JIRA] (WFCORE-1862) [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1862?page=com.atlassian.jira.plugi... ]
Radim Hatlapatka updated WFCORE-1862:
-------------------------------------
Description:
Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for WildFly 10.1.0.Final
Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final, it works just fine.
Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded)
\[1\]
{noformat}
"default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x6c393e50> (a sun.nio.ch.Util$2)
- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
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.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
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)
{noformat}
was:
Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for EAP 7.1.0.DR6
Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final (version used in EAP 7.0.2.CP), it works just fine.
Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded)
\[1\]
{noformat}
"default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x6c393e50> (a sun.nio.ch.Util$2)
- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
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.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
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)
{noformat}
> [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1862
> URL: https://issues.jboss.org/browse/WFCORE-1862
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.2.0.Final
> Environment: Noticed only on HP-UX ia64 with java version "1.8.0.04-hp-ux"
> Reporter: Radim Hatlapatka
> Assignee: David Lloyd
> Priority: Blocker
> Attachments: connector-metrics.war, duringReload.jstack, eap.jstack
>
>
> Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for WildFly 10.1.0.Final
> Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
> The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
> Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final, it works just fine.
> Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded)
> \[1\]
> {noformat}
> "default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
> at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
> at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x6c393e50> (a sun.nio.ch.Util$2)
> - locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
> - locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
> at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
> at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
> at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
> at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
> at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 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.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1862) [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1862?page=com.atlassian.jira.plugi... ]
Radim Hatlapatka moved JBEAP-6377 to WFCORE-1862:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1862 (was: JBEAP-6377)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
(was: Web (Undertow))
Affects Version/s: 2.2.0.Final
(was: 7.1.0.DR6)
Affects Testing: (was: Regression)
Fix Version/s: (was: 7.1.0.GA)
> [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1862
> URL: https://issues.jboss.org/browse/WFCORE-1862
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.2.0.Final
> Environment: Noticed only on HP-UX ia64 with java version "1.8.0.04-hp-ux"
> Reporter: Radim Hatlapatka
> Assignee: David Lloyd
> Priority: Blocker
> Attachments: connector-metrics.war, duringReload.jstack, eap.jstack
>
>
> Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for EAP 7.1.0.DR6
> Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
> The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
> Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final (version used in EAP 7.0.2.CP), it works just fine.
> Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded)
> \[1\]
> {noformat}
> "default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
> at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
> at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x6c393e50> (a sun.nio.ch.Util$2)
> - locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
> - locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
> at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
> at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
> at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
> at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
> at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 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.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5542:
-----------------------------------
2) shouldn't be an issue anymore as it looks like apache version uses different fix that should also work. But only way to be sure is to pass tck.
3) i don't see that as an issue, secure by default is better default in any case. I am surprised we don't have it as well. There (w)are bugs raised to fix that.
> Look into using apache's upstream JSTL
> --------------------------------------
>
> Key: WFLY-5542
> URL: https://issues.jboss.org/browse/WFLY-5542
> Project: WildFly
> Issue Type: Task
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1324) CNFE when stopping server with enabled scanner
by Karel Suta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugi... ]
Karel Suta reassigned DROOLS-1324:
----------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
> Key: DROOLS-1324
> URL: https://issues.jboss.org/browse/DROOLS-1324
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
> Environment: Kie server 6.5.0-SNAPSHOT
> Reporter: Karel Suta
> Assignee: Maciej Swiderski
> Priority: Minor
> Labels: reported-by-qe
> Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1324) CNFE when stopping server with enabled scanner
by Karel Suta (JIRA)
Karel Suta created DROOLS-1324:
----------------------------------
Summary: CNFE when stopping server with enabled scanner
Key: DROOLS-1324
URL: https://issues.jboss.org/browse/DROOLS-1324
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.0.0.Beta2, 6.5.0.CR2
Environment: Kie server 6.5.0-SNAPSHOT
Reporter: Karel Suta
Assignee: Edson Tirelli
Priority: Minor
Attachments: stacktrace-server.txt
When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
This exception occurs randomly, you may need to start/stop server several times to see it.
Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
by Joni Niemi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugi... ]
Joni Niemi commented on DROOLS-1199:
------------------------------------
This bug makes version 6.4.0.Final unusable in a production environment. Your options are either to downgrade or fork and make your own build.
> Memory leak in KieScanner
> -------------------------
>
> Key: DROOLS-1199
> URL: https://issues.jboss.org/browse/DROOLS-1199
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7283) Update EJB to use txn spi
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-7283:
------------------------------------
Summary: Update EJB to use txn spi
Key: WFLY-7283
URL: https://issues.jboss.org/browse/WFLY-7283
Project: WildFly
Issue Type: Enhancement
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Flavia Rainone
Priority: Minor
Fix For: 10.2.0.Final, 11.0.0.Alpha1
Remote references from EJB to internal transaction classes, replacing then by references to the spi.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7282) Deadlock in BasicAction when jboss remoting and JTA is used
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ]
Flavia Rainone updated WFLY-7282:
---------------------------------
Description:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20...
Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
IIOP/JTS does not suffer with this flaw.
was:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
Summary: Deadlock in BasicAction when jboss remoting and JTA is used (was: Double diamond in EJB Transaction)
> Deadlock in BasicAction when jboss remoting and JTA is used
> -----------------------------------------------------------
>
> Key: WFLY-7282
> URL: https://issues.jboss.org/browse/WFLY-7282
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
> Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20...
> Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
> If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
> IIOP/JTS does not suffer with this flaw.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months