November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-202: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from MODIFIED to ON_QA > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha13 > > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from MODIFIED to ON_QA > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from MODIFIED to ON_QA > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-245: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from MODIFIED to ON_QA > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from MODIFIED to ON_QA > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2806: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1166458|https://bugzilla.redhat.com/show_bug.cgi?id=1166458] from MODIFIED to ON_QA > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-259) Improve realm readiness handling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-259: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1161668|https://bugzilla.redhat.com/show_bug.cgi?id=1161668] from MODIFIED to ON_QA > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4110: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1164231|https://bugzilla.redhat.com/show_bug.cgi?id=1164231] from MODIFIED to ON_QA > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-134) Make sure CLIWrapper doesn't use default encoding

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-134?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-134: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from MODIFIED to ON_QA > Make sure CLIWrapper doesn't use default encoding > ------------------------------------------------- > > Key: WFCORE-134 > URL: https://issues.jboss.org/browse/WFCORE-134 > Project: WildFly Core > Issue Type: Bug > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > CLIWrapper is using the default encoding which might lead to issue with non US locales. > Also take advantage of this fix to remove some hard coded strings from tests. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1650) Legacy subsystem testing needs some classloading exclusion mecanism

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1650: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from MODIFIED to ON_QA > Legacy subsystem testing needs some classloading exclusion mecanism > ------------------------------------------------------------------- > > Key: WFLY-1650 > URL: https://issues.jboss.org/browse/WFLY-1650 > Project: WildFly > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.0.0.Beta1 > > > When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules. > Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. > For exemple this breaks the EAP build on a French OS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014