[JBoss JIRA] (WFLY-10000) Wildfly shutdown deadlock with active websocket session
by Marcel Šebek (JIRA)
Marcel Šebek created WFLY-10000:
-----------------------------------
Summary: Wildfly shutdown deadlock with active websocket session
Key: WFLY-10000
URL: https://issues.jboss.org/browse/WFLY-10000
Project: WildFly
Issue Type: Bug
Components: Web Sockets
Affects Versions: 12.0.0.Final
Environment: Linux - debian stretch (stable), openjdk 8.
Reporter: Marcel Šebek
Assignee: Stuart Douglas
Wildfly hangs during shutdown if a websocket session is active. @OnClose callback is called, but after that, wildfly hangs forever. Thread dump shows that two threads are in BLOCKED state:
{noformat}
"default task-7" #429 prio=5 os_prio=0 tid=0x00005609dcd78800 nid=0x4bf6 waiting for monitor entry [0x00007fadc61bd000]
java.lang.Thread.State: BLOCKED (on object monitor)
at io.undertow.websockets.jsr.ServerWebSocketContainer$10.run(ServerWebSocketContainer.java:892)
- waiting to lock <0x00000000f5fad4e0> (a io.undertow.websockets.jsr.ServerWebSocketContainer)
- locked <0x00000000f0f7edf8> (a io.undertow.websockets.jsr.ServerWebSocketContainer$10)
at io.undertow.websockets.jsr.SessionContainer.removeOpenSession(SessionContainer.java:52)
- locked <0x00000000f5fad5a0> (a io.undertow.websockets.jsr.ConfiguredServerEndpoint)
at io.undertow.websockets.jsr.UndertowSession$2.run(UndertowSession.java:370)
at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
"ServerService Thread Pool -- 50" #82 prio=5 os_prio=0 tid=0x00005609d81f1000 nid=0x48e8 waiting for monitor entry [0x00007fade862d000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
at io.undertow.websockets.jsr.SessionContainer.awaitClose(SessionContainer.java:67)
- locked <0x00000000f5fad5a0> (a io.undertow.websockets.jsr.ConfiguredServerEndpoint)
at io.undertow.websockets.jsr.ServerWebSocketContainer.close(ServerWebSocketContainer.java:779)
- locked <0x00000000f5fad4e0> (a io.undertow.websockets.jsr.ServerWebSocketContainer)
at io.undertow.websockets.jsr.ServerWebSocketContainer.close(ServerWebSocketContainer.java:784)
- locked <0x00000000f5fad4e0> (a io.undertow.websockets.jsr.ServerWebSocketContainer)
at io.undertow.websockets.jsr.Bootstrap$WebSocketListener.contextDestroyed(Bootstrap.java:128)
at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:202)
at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:252)
at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:663)
at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:660)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1145/655479276.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1146/915737155.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1146/915737155.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1146/915737155.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1146/915737155.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1146/915737155.call(Unknown Source)
at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:117)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Locked ownable synchronizers:
- None
{noformat}
There may be some other necessary conditions necessary to reproduce the issue (specific wildfly configuration, some application setup). If the issue is not clear from the thread dump, I can create some small example reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3513) StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugi... ]
Panagiotis Sotiropoulos updated WFCORE-3513:
--------------------------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat Employee' was removed.)
> StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3513
> URL: https://issues.jboss.org/browse/WFCORE-3513
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.8.Final
> Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
> Reporter: Jörg Bäsner
> Assignee: Dmitrii Tikhomirov
> Fix For: 4.0.0.Alpha6
>
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
> JAVA: java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> at java.lang.String.substring(String.java:1931)
> at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> at org.jboss.as.server.Main.main(Main.java:95)
> at org.jboss.modules.Module.run(Module.java:344)
> at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Olivier Masseau (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Olivier Masseau commented on WFLY-6173:
---------------------------------------
We also have this problem in 9.0.2.Final.
In which version has this been fixed ?
> 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: Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png, 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
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1539) Remove deprecated AuthConf setHost, setProtocol, setPort properties
by David Lloyd (JIRA)
David Lloyd created ELY-1539:
--------------------------------
Summary: Remove deprecated AuthConf setHost, setProtocol, setPort properties
Key: ELY-1539
URL: https://issues.jboss.org/browse/ELY-1539
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: David Lloyd
Priority: Critical
We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months