October 2016 - jboss-jira - Jboss List Archives

[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)

9 years, 7 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)

9 years, 7 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)

9 years, 7 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)

9 years, 7 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)

9 years, 7 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)

9 years, 7 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 reopened WFLY-6863: ---------------------------------- > 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 > Fix For: 10.1.0.CR1, 10.1.0.Final > > > 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)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBEE-168) Release new version of jboss-annotations-api_1.2_spec

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated JBEE-168: ----------------------------- Description: There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently change log {noformat} Added @Target(PARAMETER) to the Priority annotation. Made Resource and DataSourceDefinition annotations repeatable. Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications. Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. {noformat} was:There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently > Release new version of jboss-annotations-api_1.2_spec > ----------------------------------------------------- > > Key: JBEE-168 > URL: https://issues.jboss.org/browse/JBEE-168 > Project: JBoss JavaEE Spec APIs > Issue Type: Task > Components: jboss-annotations-api > Reporter: Tomas Remes > Assignee: Scott Marlow > > There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently > change log > {noformat} > Added @Target(PARAMETER) to the Priority annotation. > Made Resource and DataSourceDefinition annotations repeatable. > Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications. > Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBEE-168) Release new version of jboss-annotations-api_1.2_spec

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated JBEE-168: ----------------------------- Forum Reference: https://jcp.org/aboutJava/communityprocess/mrel/jsr250/index3.html > Release new version of jboss-annotations-api_1.2_spec > ----------------------------------------------------- > > Key: JBEE-168 > URL: https://issues.jboss.org/browse/JBEE-168 > Project: JBoss JavaEE Spec APIs > Issue Type: Task > Components: jboss-annotations-api > Reporter: Tomas Remes > Assignee: Scott Marlow > > There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

by David Maes (JIRA)

[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ] David Maes commented on WFLY-6173: ---------------------------------- [~mkouba] thank you for the quick reply. Our memory issue will probably not be caused by the jackson problem. So I think we'll have to do some investigation on our own. > Classes not unloaded after undeployment > --------------------------------------- > > Key: WFLY-6173 > URL: https://issues.jboss.org/browse/WFLY-6173 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 8.2.0.Final, 10.0.0.Final > Reporter: Joey Wang > Assignee: Martin Kouba > Priority: Blocker > Attachments: memory-leak.zip, memory-leak_New.zip > > > I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. > Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances. > Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016