November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4082: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1164213|https://bugzilla.redhat.com/show_bug.cgi?id=1164213] from MODIFIED to ON_QA > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance

by Stefan Erichsen (JIRA)

[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ] Stefan Erichsen commented on WFLY-825: -------------------------------------- Hi David, you're the best! -Dxnio.nio.old-locking=true is working! At first I was confused and tried to replace xnio-nio.jar with the one attached to this ticket. That didn't work out, after switching back to the correct jars but leaving the parameter in place it finally worked! Thank you very much! I also tried to remove the remote debugging which didn't help. Nevertheless also Thank you Tomaz for your quick help! Best regards, Stefan > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- 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: ----------------------------------------------- Hayk Hovsepyan <hhovsepy(a)redhat.com> changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from ON_QA to MODIFIED > 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] (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: ------------------------------------------------ Hynek Mlnarik <hmlnarik(a)redhat.com> changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from ON_QA to VERIFIED > 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-3794) Upgrade HornetQ to 2.5.0.Beta1

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3794?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-3794: ------------------------------ Summary: Upgrade HornetQ to 2.5.0.Beta1 (was: Upgrade HornetQ to 2.5.0.ALPHA) > Upgrade HornetQ to 2.5.0.Beta1 > ------------------------------ > > Key: WFLY-3794 > URL: https://issues.jboss.org/browse/WFLY-3794 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1470: ----------------------------------------------- Jason T. Greene <jason.greene(a)redhat.com> changed the Status of [bug 901231|https://bugzilla.redhat.com/show_bug.cgi?id=901231] from NEW to MODIFIED > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Assignee: Jason Greene > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.... ] Jason Greene reassigned WFLY-1470: ---------------------------------- Assignee: Jason Greene > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Assignee: Jason Greene > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.... ] Jason Greene resolved WFLY-1470. -------------------------------- Resolution: Done Guards have been added in the known problematic places. > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4121) Wrong LDAP host used in AdvancedLdapLoginModuleTestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4121?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4121: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1011056|https://bugzilla.redhat.com/show_bug.cgi?id=1011056] from POST to MODIFIED > Wrong LDAP host used in AdvancedLdapLoginModuleTestCase > ------------------------------------------------------- > > Key: WFLY-4121 > URL: https://issues.jboss.org/browse/WFLY-4121 > Project: WildFly > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-4096: ------------------------------------ [~shinzey] is that the entire exception call stack? Was there another deployment error also shown? Regarding WFLY-2727 "@DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners", can you show a more complete example or a test case. Even better, would be if you look at the simple [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basi...] test case and suggest what would be required to reproduce the failure. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > <data-source> > <name>java:/datasources/test</name> > <class-name>org.apache.derby.jdbc.ClientDataSource</class-name> > <database-name>test</database-name> > <url>jdbc:derby://localhost:1527/test</url> > <user>test</user> > <password>test</password> > </data-source> > {quote} > The persistence unit: > {quote} > <persistence-unit name="wtpu" transaction-type="JTA"> > <jta-data-source>java:/datasources/test</jta-data-source> > </persistence-unit> > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- 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