October 2016 - jboss-jira - Jboss List Archives

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

by Krisztian Kocsis (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] Krisztian Kocsis commented on WFLY-7275: ---------------------------------------- @David: I try to reproduce the issue, it takes some time. The main thread was show and 10108 in htop as using 100% but I think there was an other thread too (I don't remember correctly). @James: Yes, I run a periodic (every 2 minutes) EJB task that imports data from one datasource to an other datasource. > 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: Jason Greene > Attachments: 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 James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-7275: ------------------------------------- Are you using a scheduled job with the {{ManagedScheduledExecutorService}}? I didn't look in detail on the thread-dump, but noticed some parked EE concurrency threads. They don't look unusual, just trying to get an idea of what your application might be doing. > 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: Jason Greene > Attachments: 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 David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-7275: ----------------------------------- What thread? You can find out by using "ps" or "top" to display the PID of the thread, and then convert that value to hexadecimal and search for that value in the output of jstack. > 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: Jason Greene > Attachments: 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 Krisztian Kocsis (JIRA)

Krisztian Kocsis created WFLY-7275: -------------------------------------- Summary: 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: Jason Greene Attachments: 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-258) Redesign mod_cluster subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.s... ] Radoslav Husar updated WFLY-258: -------------------------------- Affects Version/s: JBoss AS7 7.1.1.Final > Redesign mod_cluster subsystem > ------------------------------ > > Key: WFLY-258 > URL: https://issues.jboss.org/browse/WFLY-258 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Changes to the schema > * simplified names and sync in line with scheme recommendations > * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem > * fix load factor enum: no pool metric supported > * make load-balancers configurable via socket-outbuound-group mechanism > * add missing load-balancer properties to <proxies/> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-258) Redesign mod_cluster subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.s... ] Radoslav Husar updated WFLY-258: -------------------------------- Summary: Redesign mod_cluster subsystem (was: mod_cluster schema 2.0) > Redesign mod_cluster subsystem > ------------------------------ > > Key: WFLY-258 > URL: https://issues.jboss.org/browse/WFLY-258 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Changes to the schema > * simplified names and sync in line with scheme recommendations > * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem > * fix load factor enum: no pool metric supported > * make load-balancers configurable via socket-outbuound-group mechanism > * add missing load-balancer properties to <proxies/> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2109) S3_PING: add support for instance metadata

by Kerem Kacel (JIRA)

Kerem Kacel created JGRP-2109: --------------------------------- Summary: S3_PING: add support for instance metadata Key: JGRP-2109 URL: https://issues.jboss.org/browse/JGRP-2109 Project: JGroups Issue Type: Feature Request Reporter: Kerem Kacel Assignee: Bela Ban The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance). The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files. Are there any plans to add official support for this in JGroups? Resources: http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.... http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html Example third-party protocols: https://github.com/tagbangers/jgroups-s3-client-ping https://github.com/mcacker/jgroups-native-s3-ping -- 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)

Richard Opalka created WFCORE-1859: -------------------------------------- Summary: 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 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-5239: -------------------------------------- You can easily set node0/1 to one address and node2/3 to the other one.. > XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for" > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-5239 > URL: https://issues.jboss.org/browse/WFLY-5239 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 10.0.0.Beta2 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known: > {noformat} > rhusar &amp#27;[0m&amp#27;[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war") > &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100 > &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000) > &amp#27;[0mExecuted HTTP request > &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message > &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2108) TCP_NIO2: make default

by Bela Ban (JIRA)

Bela Ban created JGRP-2108: ------------------------------ Summary: TCP_NIO2: make default Key: JGRP-2108 URL: https://issues.jboss.org/browse/JGRP-2108 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.1 This requires the following things: * performance of {{TCP_NIO2}} must be better than {{TCP}} * (possibly) use multiple selectors: each selector handles only a max number of connections; create more selectors when the number of connections per selector exceeds a certain value * (possibly) get rid of the reader thread and let the above selector do the read (the write is already done by the selector thread) -- 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