August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3619: ------------------------------------ I got the answer to my question #1 above but not the logging information for #2 (need TRACE log output for org.jboss.jca, org.hibernate, org.jboss.as.jpa + com.arjuna). Would also be interesting to know what is observed with the latest WildFly nightly build ([https://community.jboss.org/thread/224262]). > XA END / un-enlist for database connection called to early > ---------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Scott Marlow > Priority: Blocker > Attachments: server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3720) Run clustering tests with ttl=0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3720?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3720: --------------------------------- Affects Version/s: 8.0.0.Final > Run clustering tests with ttl=0 > ------------------------------- > > Key: WFLY-3720 > URL: https://issues.jboss.org/browse/WFLY-3720 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Best we could probably change the xml in the subsystem. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-696) Log message too cryptic when deployment references a non-existent configuration in profile config

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-696?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-696: ---------------------------------------------- Martin Svehla <msvehla(a)redhat.com> changed the Status of [bug 900892|https://bugzilla.redhat.com/show_bug.cgi?id=900892] from NEW to CLOSED > Log message too cryptic when deployment references a non-existent configuration in profile config > ------------------------------------------------------------------------------------------------- > > Key: WFLY-696 > URL: https://issues.jboss.org/browse/WFLY-696 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: Awaiting Volunteers > > Attachments: helloWorld.ear, helloWorld.ear-source.zip > > > When a jboss-ejb-client.xml inside of a deployment that references an outbound-socket that does not exist in the standalone.xml, it logs a cryptic message and does not explain where the issue is. Note when a deployment contains more sub deployements, the log message is much larger and the issue if you know what to look for is hidden in the middle. > 15:41:01,189 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.ejb3.dd-based-ejb-client-context.\"helloWorld.ear\" Missing[jboss.remoting.endpoint.subsystem.outbound-connection.part101node01-connection]","jboss.deployment.subunit.\"helloWorld.ear\".\"helloWorld.war\".INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"helloWorld.ear\".INSTALL Missing[JBAS014861: <one or more transitive dependencies>]"]}}} > The error message should be translated to say something to the extent of > "Your deployment helloWorld.ear contains a jboss-ejb-client.xml which references an outbound-socket named part101node01 which is not defined in your JBoss profile's remoting subsystem configuration" > jboss.ejb3.dd-based-ejb-client-context.\"helloWorld.ear - this shows that helloWorld.ear is the deployment, jboss.ejb3.dd-based-ejb-client-context seems to the jboss-ejb-client.xml > jboss.remoting.endpoint.subsystem.outbound-connection.part101node01-connection - this shows that the subsystem that is missing the outbound-configuration is the remoting subsystem and that the reference name missing is part101node01 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1832) Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1832: --------------------------- Fix Version/s: (was: 3.4.5) > Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups > ------------------------------------------------------------------------------------------ > > Key: JGRP-1832 > URL: https://issues.jboss.org/browse/JGRP-1832 > Project: JGroups > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 3.4.3 > Reporter: Dennis Reed > Assignee: Dennis Reed > Priority: Optional > Fix For: 3.6 > > > JGroups binds multicast sockets using specific MulticastSocket constructors depending on the operating system (to avoid crosstalk issues). > McastSenderTest and McastReceiverTest always bind the socket using the basic MulticastSocket(port) constructor. > In order to more closely test the way JGroups will be sending and receiving the packets, these tests will be updated to bind the sockets the same way. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1869. ---------------------------- Fix Version/s: (was: 3.4.5) Resolution: Done > TP.registerProbeHandler not thread safe > --------------------------------------- > > Key: JGRP-1869 > URL: https://issues.jboss.org/browse/JGRP-1869 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization. > If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers. > Access to preregistered_probe_handlers should be synchronized. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3248) Removing ViewChangeListener* broke the extended clustering testsuite

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-3248: -------------------------------------- Assing back to me if you want me to take a look, I just run the tests at this point. > Removing ViewChangeListener* broke the extended clustering testsuite > -------------------------------------------------------------------- > > Key: WFLY-3248 > URL: https://issues.jboss.org/browse/WFLY-3248 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, Test Suite > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > > What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests. > The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3248) Removing ViewChangeListener* broke the extended clustering testsuite

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3248?page=com.atlassian.jira.plugin.... ] Radoslav Husar reopened WFLY-3248: ---------------------------------- Assignee: Paul Ferraro (was: Radoslav Husar) I have rerun the tests and all the async tests still actually fail horribly. Any chance you omitted the {{-DextendedTests}} parameters for the testsuite run? The failures seem to indicate timing issues. {noformat} StatefulFailoverTestCase.noFailover:134 expected:<1> but was:<0> StatefulFailoverTestCase.simpleFailover:152->failover:211 expected:<9> but was:<7> CdiFailoverTestCase.testGracefulUndeployFailover:123->testFailoverOnUndeploy:195 expected:<9> but was:<7> CdiFailoverTestCase.testGracefulSimpleFailover:101->testFailoverOnShutdown:137->queryCount:219 expected:<200> but was:<500> SharedSessionFailoverTestCase.test:125 expected:<3> but was:<2> CoarseSessionExpirationTestCase>SessionExpirationTestCase.test:100 null FineSessionExpirationTestCase>SessionExpirationTestCase.test:152 expected:<[2]> but was:<[1]> ClusteredSingleSignOnTestCase.testNoAuthSingleSignOn:143 Get of http://127.0.0.1:8180//war2/index.html redirected to login page {noformat} > Removing ViewChangeListener* broke the extended clustering testsuite > -------------------------------------------------------------------- > > Key: WFLY-3248 > URL: https://issues.jboss.org/browse/WFLY-3248 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, Test Suite > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > > What we did a while back, we made the sync-tcp the default configuration for running the clustering tests. However, we kept a extended testsuite with other combinations and other unimportant clustering tests. > The async combinations partly relied on the ViewChangeListener* mechanisms. This was not detected earlier because this part of TS is not run by default on the CI. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-87) NDC formatting is wrong with AsyncHandler

by Ebbe George Haabendal Brandstrup (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-87?page=com.atlassian.jira.plugin.... ] Ebbe George Haabendal Brandstrup commented on LOGMGR-87: -------------------------------------------------------- I am eagerly awaiting this to be resolved. I'm doing a nasty hack to be able to use async handlers while also getting NDC info into my logs... both are (completely standard I should think) requirements in my project. Thanks. > NDC formatting is wrong with AsyncHandler > ----------------------------------------- > > Key: LOGMGR-87 > URL: https://issues.jboss.org/browse/LOGMGR-87 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Valter Karacek > Assignee: James Perkins > > NDC information is not logged when used with asynchronous log handler. > The problem appears to be with Formatters.ndcFormatStep that return the value from NDC class, instead getting from ExtLogRecord.getNdc(). > <pattern-formatter pattern="%d | %-5p | [%c] | (%t:%x) | %m%n"/> -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early

by Rob Heine (JIRA)

[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ] Rob Heine commented on WFLY-3619: --------------------------------- Since Andreas is in vacation, is any further information required? > XA END / un-enlist for database connection called to early > ---------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Scott Marlow > Priority: Blocker > Attachments: server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3725) Unable to deploy dynamic, programmatic JSR-356 Endpoints

by Jim Crossley (JIRA)

[ https://issues.jboss.org/browse/WFLY-3725?page=com.atlassian.jira.plugin.... ] Jim Crossley commented on WFLY-3725: ------------------------------------ I see the same behavior in WF upstream, Stuart. Is there an integration test somewhere that makes you think it should work? > Unable to deploy dynamic, programmatic JSR-356 Endpoints > --------------------------------------------------------- > > Key: WFLY-3725 > URL: https://issues.jboss.org/browse/WFLY-3725 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Jim Crossley > Assignee: Stuart Douglas > > I'm following the example here: https://github.com/undertow-io/undertow/blob/ceb019c91bd5ff5f219093298be9... > I'm dynamically creating a Servlet instance and deploying it using the the ServletContext's addServlet method. The servlet init's method is similar to the above test case, obtaining a ServerContainer and calling its addEndpoint method with a ServerEndpointConfig$Configurator. > Everything works fine in standalone Undertow 1.0.15.Final, but in WildFly 8.1, I see the following: > [io.undertow.websockets.jsr] (MSC service thread 1-1) UT026005: Adding programmatic server endpoint class immutant.web.internal.servlet.proxy$javax.websocket.Endpoint$ff19274a for path / > And then my configurator never gets called when I attempt to connect. It's as if the upgrade is never attempted, i.e. like the request protocol is 'http://' instead of 'ws://' but I know it's 'ws://' because the same client works fine against Undertow standalone. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 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 August 2014