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 asked about the "Skipping JTA sync registration due to auto join checking on [http://lists.jboss.org/pipermail/hibernate-dev/2014-August/011650.html]. I'm not yet sure if that is wrong or not yet. > 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-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, 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] (JBJCA-1209) IronJacamar 1.0.27.Final

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1209?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1209. ------------------------------------ Resolution: Done > IronJacamar 1.0.27.Final > ------------------------ > > Key: JBJCA-1209 > URL: https://issues.jboss.org/browse/JBJCA-1209 > Project: IronJacamar > Issue Type: Release > Security Level: Public(Everyone can see) > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.27.Final > > > Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3716) Upgrade JAXB to 2.2.5.jboss-2 for bug fixes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3716?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3716: ----------------------------------------------- Navin Surtani <nsurtani(a)redhat.com> changed the Status of [bug 1127326|https://bugzilla.redhat.com/show_bug.cgi?id=1127326] from ASSIGNED to POST > Upgrade JAXB to 2.2.5.jboss-2 for bug fixes > ------------------------------------------- > > Key: WFLY-3716 > URL: https://issues.jboss.org/browse/WFLY-3716 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: XML Frameworks > Reporter: Paul Gier > Assignee: Paul Gier > > Upgrade jaxb to 2.2.5.jboss-2 to include some bug fixes. -- 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 Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3619: ------------------------------------ I'm not sure why we are seeing this message: {quote} 2014-08-14 09:24:19,357 DEBUG [org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl] (EJB default - 6) Skipping JTA sync registration due to auto join checking {quote} Also, org.jboss.jpa should be org.jboss.as.jpa > 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-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, 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] (JBJCA-1209) IronJacamar 1.0.27.Final

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1209: -------------------------------------- Summary: IronJacamar 1.0.27.Final Key: JBJCA-1209 URL: https://issues.jboss.org/browse/JBJCA-1209 Project: IronJacamar Issue Type: Release Security Level: Public (Everyone can see) Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.27.Final Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1196) Backport SemaphoreConcurrentLinkedQueueManagedConnectionPool

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1196?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1196: ----------------------------------- Fix Version/s: 1.0.28.Final (was: 1.0.27.Final) > Backport SemaphoreConcurrentLinkedQueueManagedConnectionPool > ------------------------------------------------------------ > > Key: JBJCA-1196 > URL: https://issues.jboss.org/browse/JBJCA-1196 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: John O'Hara > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final > > > Can we backport the SemaphoreConcurrentLinkedQueueManagedConnectionPool to 1.0 and 1.1 branches. We will need this to be pulled into EAP6.4 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1513) remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1513?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1513: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1127586 > remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI > --------------------------------------------------------------------------------------------- > > Key: WFLY-1513 > URL: https://issues.jboss.org/browse/WFLY-1513 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, JMS > Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2 > Reporter: jaikiran pai > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > The remove (management) operation on a JMS queue merely unbinds the queue from JNDI instead of destroying the queue. It appears that the change was done as part of https://issues.jboss.org/browse/AS7-1899 (the PR is here https://github.com/wildfly/wildfly/pull/398). The change done in that PR to address the original issue reported in that other JIRA doesn't look right. > So the original issue reported in that thread is that a server has a queue with messages and the server is stopped. Upon restart the messages have disappeared because upon stop, the JMSQueueService's stop() method used to destroy the queue. The real fix would have been to differentiate the "remove()" operation from a mere service stop. The explicit remove (handler) would then be responsible for destroying the queue (which even means a JNDI unbind) and not that service's stop method. > All of this even applies to the JMS topic which has a similar problem. > On a related note, the add() operation too seems suspicious because it ends up calling a createXXX on the JMSServer API which says: > {code} > /** > * Creates a JMS Queue. > * > * @param queueName > * The name of the queue to create > * @param selectorString > * @param durable > * @return true if the queue is created or if it existed and was added to > * JNDI > * @throws Exception > * if problems were encountered creating the queue. > */ > boolean createQueue(boolean storeConfig, String queueName, String selectorString, boolean durable, String ...bindings) throws Exception; > {code} > Notice the "if the queue is created or if it existed and was added to JNDI" part. So it appears that the management "add" operation can end up behaving like an update (write-attribute) kind of operation in some cases. I'm not sure if that's good thing. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-568) Module dependencies missing from brms and bpms layers to support remote runtime engines

by Jeremy Lindop (JIRA)

[ https://issues.jboss.org/browse/DROOLS-568?page=com.atlassian.jira.plugin... ] Jeremy Lindop commented on DROOLS-568: -------------------------------------- Additional commits for fixes to the org.kie.remote module and its generation. https://github.com/droolsjbpm/kie-wb-distributions/commit/15b136c089c8877... https://github.com/droolsjbpm/kie-wb-distributions/commit/0a7055752469edf... https://github.com/droolsjbpm/kie-wb-distributions/commit/974472a662241e9... https://github.com/droolsjbpm/kie-wb-distributions/commit/8234666d9959790... https://github.com/droolsjbpm/kie-wb-distributions/commit/10b8399568ee396... My tests now run without errors. > Module dependencies missing from brms and bpms layers to support remote runtime engines > --------------------------------------------------------------------------------------- > > Key: DROOLS-568 > URL: https://issues.jboss.org/browse/DROOLS-568 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR2 > Environment: JBoss EAP 6.3 > Reporter: David Ward > Assignee: Jeremy Lindop > > Regarding artifacts: > org.kie:kie-eap-distributions-brms-layer::6.1.0.CR2 > org.kie:kie-eap-integration-brms:brms-layer:6.0.2-redhat-7 > org.kie:kie-eap-distributions-bpms-layer::6.1.0.CR2 > org.kie:kie-eap-integration-bpms:bpms-layer:6.0.2-redhat-7 > And these modules: > modules/system/layers/brms/org/kie/main/module.xml > modules/system/layers/bpms/org/kie/main/module.xml > There are missing libraries needed to support the remote rest and jms runtime engine factories (and associated builders): > org.kie.services.client.api.RemoteJmsRuntimeEngineFactory/Builder > org.kie.services.client.api.RemoteRestRuntimeEngineFactory/Builder > Including at least these resource-roots: > org.kie.remote:kie-services-client > org.kie.remote:kie-services-jaxb > and this dependency module: > org.jboss.resteasy:resteasy-jackson-provider > (Although still validating other possible dependencies.) > Without having all the necessary libraries included and dependencies linked, using the RemoteRuntimeEngines via kie-services-client is not possible. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-44) Add a TrivialSaltedDigestPassword

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-44: ----------------------------------- Summary: Add a TrivialSaltedDigestPassword Key: ELY-44 URL: https://issues.jboss.org/browse/ELY-44 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: Password Types Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 The following is in use by ApacheDS at the very least: - http://www.ietf.org/archive/id/draft-stroeder-hashed-userpassword-values-... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-297: ----------------------------------------- Does this need to be an extra profile? Can't the enforcer rule be smart enough to do the following "if the version of this module is not a SNAPSHOT, then it should have no SNAPSHOT dependencies"? > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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