May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-140) Connection leak caused by failed transaction integration

by Dmitry Telegin (Jira)

[ https://issues.redhat.com/browse/AG-140?page=com.atlassian.jira.plugin.sy... ] Dmitry Telegin updated AG-140: ------------------------------ Description: If the following conditions are met: - transaction integration is installed; - connection checkout has been successful; - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception, then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion. The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active): {code:java} Foo foo = new Foo(); try { em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted } catch (Exception e) { // suppress exception LOG.log(Level.WARNING, "merge", e); } // continue using the same EntityManager em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked {code} Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager afterwards), but it shouldn't lead to connection leaks either. The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc was: If the following conditions are met: - transaction integration is installed; - connection checkout has been successful; - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception, then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion. The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active): {code:java} Foo foo = new Foo(); try { em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted } catch (Exception e) { // suppress exception LOG.log(Level.WARNING, "merge", e); } // continue using the same EntityManager em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked {code} Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager), but it shouldn't lead to connection leaks. The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc > Connection leak caused by failed transaction integration > -------------------------------------------------------- > > Key: AG-140 > URL: https://issues.redhat.com/browse/AG-140 > Project: Agroal > Issue Type: Bug > Components: narayana, pool > Affects Versions: 1.8 > Reporter: Dmitry Telegin > Assignee: Luis Barreiro > Priority: Major > > If the following conditions are met: > - transaction integration is installed; > - connection checkout has been successful; > - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception, > then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion. > The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active): > {code:java} > Foo foo = new Foo(); > try { > em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted > } catch (Exception e) { > // suppress exception > LOG.log(Level.WARNING, "merge", e); > } > > // continue using the same EntityManager > em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked > {code} > Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager afterwards), but it shouldn't lead to connection leaks either. > The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AG-140) Connection leak caused by failed transaction integration

by Dmitry Telegin (Jira)

Dmitry Telegin created AG-140: --------------------------------- Summary: Connection leak caused by failed transaction integration Key: AG-140 URL: https://issues.redhat.com/browse/AG-140 Project: Agroal Issue Type: Bug Components: narayana, pool Affects Versions: 1.8 Reporter: Dmitry Telegin Assignee: Luis Barreiro If the following conditions are met: - transaction integration is installed; - connection checkout has been successful; - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception, then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion. The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active): {code:java} Foo foo = new Foo(); try { em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted } catch (Exception e) { // suppress exception LOG.log(Level.WARNING, "merge", e); } // continue using the same EntityManager em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked {code} Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager), but it shouldn't lead to connection leaks. The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1964) Some SecurityRealm implementations use wrong exception types when unavailable

by Martin Mazánek (Jira)

Martin Mazánek created ELY-1964: ----------------------------------- Summary: Some SecurityRealm implementations use wrong exception types when unavailable Key: ELY-1964 URL: https://issues.redhat.com/browse/ELY-1964 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Mazánek Assignee: Martin Mazánek Some SecurityRealm implementations use wrong exception types when unavailable, as opposed to RealmUnavailableException specified by the SPI. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13470) Provide SPI and implementation for building a client mappings registry per connector

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13470: ----------------------------------- Summary: Provide SPI and implementation for building a client mappings registry per connector Key: WFLY-13470 URL: https://issues.redhat.com/browse/WFLY-13470 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13469) Decouple distributed SFSB cache from client mappings registry.

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13469: ----------------------------------- Summary: Decouple distributed SFSB cache from client mappings registry. Key: WFLY-13469 URL: https://issues.redhat.com/browse/WFLY-13469 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 19.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro To facilitate multiple client mappings registries per remote connector, we need to decouple the SFSB cache from the client mappings registry. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1145) need at least Go 1.14.1 to build Kiali now

by Matthew Mahoney (Jira)

[ https://issues.redhat.com/browse/SWSQE-1145?page=com.atlassian.jira.plugi... ] Matthew Mahoney reassigned SWSQE-1145: -------------------------------------- Assignee: Filip Brychta > need at least Go 1.14.1 to build Kiali now > ------------------------------------------ > > Key: SWSQE-1145 > URL: https://issues.redhat.com/browse/SWSQE-1145 > Project: Kiali QE > Issue Type: QE Task > Reporter: John Mazzitelli > Assignee: Filip Brychta > Priority: Major > > See: https://github.com/kiali/kiali/issues/2779 > We need Jenkins to build with at minimum Go 1.14.1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1145) need at least Go 1.14.1 to build Kiali now

by John Mazzitelli (Jira)

John Mazzitelli created SWSQE-1145: -------------------------------------- Summary: need at least Go 1.14.1 to build Kiali now Key: SWSQE-1145 URL: https://issues.redhat.com/browse/SWSQE-1145 Project: Kiali QE Issue Type: QE Task Reporter: John Mazzitelli See: https://github.com/kiali/kiali/issues/2779 We need Jenkins to build with at minimum Go 1.14.1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1142) UI Automations to Istio 1.6

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1142?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan resolved SWSQE-1142. ----------------------------------- Resolution: Done https://github.com/Kiali-QE/kiali-qe-python/pull/288 > UI Automations to Istio 1.6 > --------------------------- > > Key: SWSQE-1142 > URL: https://issues.redhat.com/browse/SWSQE-1142 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3685) [DMN Designer] Boxed expressions - Decision Table - Output clause - Show Data Type fields automatically

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3685?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-3685: ------------------------------------ Description: When users select a "Structured" Data Type in a Decision Table output clause, the Data Type fields should be automatically shown as "sub-cells". (was: When users select a "Structured" Data Type in a Decision Table output clause, the Data Type fields should be automatically shown as "sub-cells". ⚠️ Notice: Before starting this issue, check about a possible limitation for the number of automatically created columns.) > [DMN Designer] Boxed expressions - Decision Table - Output clause - Show Data Type fields automatically > ------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3685 > URL: https://issues.redhat.com/browse/DROOLS-3685 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > When users select a "Structured" Data Type in a Decision Table output clause, the Data Type fields should be automatically shown as "sub-cells". -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9856) [JDK9+] org.jboss.security.negotiation package is exported by two jars

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-9856?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFLY-9856. ------------------------------------ Resolution: Won't Do > [JDK9+] org.jboss.security.negotiation package is exported by two jars > ---------------------------------------------------------------------- > > Key: WFLY-9856 > URL: https://issues.redhat.com/browse/WFLY-9856 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaž Cerar > Assignee: Darran Lofthouse > Priority: Major > > Currently if you have > jboss-negotiation-common-3.0.4.Final.jar and jboss-negotiation-extras-3.0.4.Final.jar > on your module path, jvm complains as both jars export package org.jboss.security.negotiation package > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules jboss.negotiation.common and jboss.negotiation.extras export package org.jboss.security.negotiation to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 May 2020