October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9 modular params propagation to forked processes

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugi... ] Richard Opalka commented on WFCORE-1859: ---------------------------------------- On JDK 9 it is necessary (at least for now) to run WildFly's DomainController, HostController and ServerInstance with some modular options present on command line to make them work. It is not clear if JDK 9 modular params should be copied from DomainController to HostController and further from HostController to ServerInstance or these options should be configured separately and different way. Anyway this issue will be addressed in near future. For now I'm sending temporary solution to make WildFly-Core at least work on JDK9 so we can track the regressions as JDK9 EAs are released. > Investigate and fix JDK9 modular params propagation to forked processes > ----------------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7293) Wildfly eats the CPU up to 100% and does not respond

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7293: ------------------------------------ Summary: Wildfly eats the CPU up to 100% and does not respond Key: WFLY-7293 URL: https://issues.jboss.org/browse/WFLY-7293 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit Reporter: Krisztian Kocsis Assignee: Stuart Douglas Hi! I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server. It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile. I'v attached the stack trace but I unfortunately don't see anything according to my knowledge. Please help me, I can provide more information if necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to 100% and does not respond

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-7275: -------------------------------------- I have submitted an XNIO pull request that should fix this. I think the problem is caused by the use of CONNECTION_HIGH_WATER to control the max number of connections. > Wildfly eats the CPU up to 100% and does not respond > ---------------------------------------------------- > > Key: WFLY-7275 > URL: https://issues.jboss.org/browse/WFLY-7275 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit > Reporter: Krisztian Kocsis > Assignee: Stuart Douglas > Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt > > > Hi! > > I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server. > It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile. > > I'v attached the stack trace but I unfortunately don't see anything according to my knowledge. > Please help me, I can provide more information if necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to 100% and does not respond

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-7275: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Wildfly eats the CPU up to 100% and does not respond > ---------------------------------------------------- > > Key: WFLY-7275 > URL: https://issues.jboss.org/browse/WFLY-7275 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit > Reporter: Krisztian Kocsis > Assignee: Stuart Douglas > Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt > > > Hi! > > I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server. > It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile. > > I'v attached the stack trace but I unfortunately don't see anything according to my knowledge. > Please help me, I can provide more information if necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7292) Wildfly eats the CPU up to 100% and does not respond

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7292: ------------------------------------ Summary: Wildfly eats the CPU up to 100% and does not respond Key: WFLY-7292 URL: https://issues.jboss.org/browse/WFLY-7292 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit Reporter: Krisztian Kocsis Assignee: Jason Greene Hi! I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server. It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile. I'v attached the stack trace but I unfortunately don't see anything according to my knowledge. Please help me, I can provide more information if necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9 modular params propagation to forked processes

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-1859: ----------------------------------- Summary: Investigate and fix JDK9 modular params propagation to forked processes (was: Investigate JDK9 modular params propagation to forked processes) > Investigate and fix JDK9 modular params propagation to forked processes > ----------------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1859) Investigate JDK9 modular params propagation to forked processes

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-1859: ----------------------------------- Priority: Blocker (was: Major) > Investigate JDK9 modular params propagation to forked processes > --------------------------------------------------------------- > > Key: WFCORE-1859 > URL: https://issues.jboss.org/browse/WFCORE-1859 > Project: WildFly Core > Issue Type: Sub-task > Components: Server, Test Suite > Reporter: Richard Opalka > Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7280) getSession() Always Creating HttpSession Problem

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7280. ---------------------------------- Resolution: Cannot Reproduce Bug You are going to need to provide more details about how to reproduce this. > getSession() Always Creating HttpSession Problem > ------------------------------------------------- > > Key: WFLY-7280 > URL: https://issues.jboss.org/browse/WFLY-7280 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: jdk8u102, win7x64, wildfly-servlet-10.1.0.Final.tar.gz > Reporter: kin zhu > Assignee: Stuart Douglas > > I have a login application called cas.war. I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null. I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request). I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) : > {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java, method getSession:{color} > {code:java} > public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) { > SessionConfig c = originalServletContext.getSessionConfig(); > HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey); > {code} > while > sessionAttachmentKey = {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color} > > the exchange.attachments map will only contain one such key: {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color} > thus the server will create new session once request.getSession() is called, regardless one session exist or not. > And please have a look at the relate class InMemorySessionManager too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6863: --------------------------------- Priority: Major (was: Minor) > Excluded contexts which are not specific to a host should be excluded on all hosts > ---------------------------------------------------------------------------------- > > Key: WFLY-6863 > URL: https://issues.jboss.org/browse/WFLY-6863 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > With the following configuration: > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" > loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" > loadMetricCapacity="1" > loadHistory="9" > loadDecayFactor="2" > stickySession="true" > stickySessionForce="false" > stickySessionRemove="true" > advertise="true" > advertiseGroupAddress="224.0.1.105" > advertisePort="23364" > advertiseInterface="10.40.4.50" > excludedContexts="ROOT,docs,manager,host-manager,examples" > /> > {code} > And these contexts in webapps: > {code} > clusterbench docs examples host-manager manager ROOT > {code} > One expects this output on Mod_cluster manger console: > {code} > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > It works, unless you configure additional VirtualHosts: > {code} > <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true"> > <Alias>LOCALHOST</Alias> > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > </Host> > <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true"> > <Alias>KARM.BRQ.REDHAT.COM</Alias> > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > </Host> > {code} > result: > {code} > Node worker1 (ajp://10.40.4.50:8009): > Enable Contexts Disable Contexts Stop Contexts > Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100 > Virtual Host 2: > Contexts: > /docs, Status: ENABLED Request: 0 Disable Stop > /manager, Status: ENABLED Request: 0 Disable Stop > /host-manager, Status: ENABLED Request: 0 Disable Stop > /examples, Status: ENABLED Request: 0 Disable Stop > /, Status: ENABLED Request: 0 Disable Stop > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > karm.brq.redhat.com > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't. > WDYT? Is it possible to tweak with the Listener's configuration somehow? > THX. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6863: --------------------------------- Fix Version/s: (was: 10.1.0.CR1) (was: 10.1.0.Final) > Excluded contexts which are not specific to a host should be excluded on all hosts > ---------------------------------------------------------------------------------- > > Key: WFLY-6863 > URL: https://issues.jboss.org/browse/WFLY-6863 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > With the following configuration: > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" > loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" > loadMetricCapacity="1" > loadHistory="9" > loadDecayFactor="2" > stickySession="true" > stickySessionForce="false" > stickySessionRemove="true" > advertise="true" > advertiseGroupAddress="224.0.1.105" > advertisePort="23364" > advertiseInterface="10.40.4.50" > excludedContexts="ROOT,docs,manager,host-manager,examples" > /> > {code} > And these contexts in webapps: > {code} > clusterbench docs examples host-manager manager ROOT > {code} > One expects this output on Mod_cluster manger console: > {code} > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > It works, unless you configure additional VirtualHosts: > {code} > <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true"> > <Alias>LOCALHOST</Alias> > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > </Host> > <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true"> > <Alias>KARM.BRQ.REDHAT.COM</Alias> > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" > prefix="localhost_access_log" suffix=".txt" > pattern="%h %l %u %t "%r" %s %b" /> > </Host> > {code} > result: > {code} > Node worker1 (ajp://10.40.4.50:8009): > Enable Contexts Disable Contexts Stop Contexts > Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100 > Virtual Host 2: > Contexts: > /docs, Status: ENABLED Request: 0 Disable Stop > /manager, Status: ENABLED Request: 0 Disable Stop > /host-manager, Status: ENABLED Request: 0 Disable Stop > /examples, Status: ENABLED Request: 0 Disable Stop > /, Status: ENABLED Request: 0 Disable Stop > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > karm.brq.redhat.com > Virtual Host 1: > Contexts: > /clusterbench, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > {code} > I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't. > WDYT? Is it possible to tweak with the Listener's configuration somehow? > THX. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016