[Red Hat JIRA] (AG-154) Connection leak when DB connection closed during transaction rollback
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-154?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro commented on AG-154:
----------------------------------
Hello [~wojciechkopciewicz],
Ran the Quarkus version you mentioned (1.9.2.Final — it has agroal 1.8 and postgresql-jdbc 42.2.16) with 100 initial connections and were unable to reproduce a leak. I tried to shutdown the java process in several ways, but in the end the database never reported any leaked connections.
Is there anything particular in the way you start and stop Quarkus ??
The life-cycle of data-sources on Quarkus is managed by CDI. Are you injecting the data-source or creating it yourself ?? Could there be anything preventing `@PreDestroy` methods from running ??
> Connection leak when DB connection closed during transaction rollback
> ---------------------------------------------------------------------
>
> Key: AG-154
> URL: https://issues.redhat.com/browse/AG-154
> Project: Agroal
> Issue Type: Bug
> Components: narayana, pool
> Affects Versions: 1.9
> Reporter: Wojciech Kopciewicz
> Assignee: Luis Barreiro
> Priority: Critical
>
> We are using Quarkus 1.9.2 with Hibernate and Agroal to access PostgreSQL DB.
> It looks like Agroal is leaking connections when connection is closed (somewhere) on the server side during transaction rollback.
> The following log was observed:
> Error trying to transactionRollback local transaction: This connection has been closed.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (SWSQE-1192) Onboar to One OCP deploy
by Filip Brychta (Jira)
[ https://issues.redhat.com/browse/SWSQE-1192?page=com.atlassian.jira.plugi... ]
Filip Brychta commented on SWSQE-1192:
--------------------------------------
It should now also support OpenShift dedicated - https://projects.engineering.redhat.com/browse/ONEOCPDEPL-43
> Onboar to One OCP deploy
> ------------------------
>
> Key: SWSQE-1192
> URL: https://issues.redhat.com/browse/SWSQE-1192
> Project: Kiali QE
> Issue Type: Story
> Reporter: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> {color:#000000}Onboard doc - [https://docs.google.com/document/d/1y9zEufKQt279dBFEaOIosEs860lC5KYex-Me1...
>
> {color:#000000}One OCP Deploy is a container solution for deploying OpenShift, based on the OCP QE team’s Flexy installer. The development team’s goal is to enable 100% of all QE OCP deployment needs with this solution. It can operate both standalone and integrated in Jenkins as a node.{color}
>
> {color:#000000}Based on multiple teams requests, the need to smoothen OCP deployment and most importantly help everyone to save time and get some reliability for deployment QE leadership asked that ALL QE teams use One OCP Deploy to deploy OpenShift. The only exception is a team that uses the IPI installer directly, with no additional tooling. {color}{color:#000000}The deadline for onboarding is Oct 4, 2020. {color}{color:#000000}If you have any questions, or feel that your team should have an additional exception, please be in touch with Sim - [sim@redhat.com|mailto:sim@redhat.com].{color}
>
> {color:#000000}One OCP Deploy is ready for GA deployment. Because the self-service documentation isn’t fully completed, the One OCP Deploy team will be happy to help teams with onboarding. We will follow the documentation during initial onboarding, and fill in anything missing so that it should be ready for self-onboarding very quickly. The onboarding documentation, including the Jira project can be found here: {color}[+https://docs.google.com/document/d/1y9zEufKQt279dBFEaOIosEs860lC5KYex-Me1BT_1pU/edit+]{color:#000000} {color}
>
> {color:#000000}We’re also asking every team that deploys OpenShift using any method to put the details into the following spreadsheet: {color}[+https://docs.google.com/spreadsheets/d/1R6eDSywHxesaoGBrOZmzzE9s5Woe9PNtUQKDhnANOG4/edit#gid=0+]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-13617) Hibernate DataSourceBasedMultiTenantConnectionProviderImpl does not work for Multitenancy
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13617?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13617:
-------------------------------------
[~rafagsam] Sorry for the delay, I think that you should look at the Hibernate ORM 5.3 source tree to see if you can figure out if an enhancement could be made to support your use. Some links:
github.com/hibernate/hibernate-orm is the main (master) branch and https://github.com/hibernate/hibernate-orm/tree/5.3 is the 5.3 branch for Hibernate ORM. Perhaps you will be able to identify a possible code change to avoid the failure you are seeing.
> Hibernate DataSourceBasedMultiTenantConnectionProviderImpl does not work for Multitenancy
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-13617
> URL: https://issues.redhat.com/browse/WFLY-13617
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 19.1.0.Final, 20.0.0.Final
> Reporter: Rafael Sampaio
> Assignee: Scott Marlow
> Priority: Minor
>
> Hello All,
> I was using o the DataSourceBasedMultiTenantConnectionProviderImpl contained in Hibernate lib to perform DATABASE MultitenancyType up to Wildfly 18.
> Upgrading to version 19 (tested on 20 too), upon initialization of my application I get the error:
>
> {noformat}
> 14:07:52,655 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.persistenceunit."web-5.0.0#appPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."web-5.0.0#appPU": org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]14:07:52,655 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.persistenceunit."web-5.0.0#appPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."web-5.0.0#appPU": org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment] at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:198) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:128) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:658) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:212) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485)Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment] at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:275) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:237) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory.injectServices(DefaultIdentifierGeneratorFactory.java:152) at org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:286) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:243) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.boot.internal.InFlightMetadataCollectorImpl.<init>(InFlightMetadataCollectorImpl.java:179) at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:119) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:1215) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1246) at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:170) ... 9 more
> Caused by: org.hibernate.HibernateException: Improper set up of DataSourceBasedMultiTenantConnectionProviderImpl at org.hibernate.engine.jdbc.connections.spi.DataSourceBasedMultiTenantConnectionProviderImpl.injectServices(DataSourceBasedMultiTenantConnectionProviderImpl.java:80) at org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:286) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:243) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.buildJdbcConnectionAccess(JdbcEnvironmentInitiator.java:149) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:66) at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:35) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:94) at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263) ... 21 more{noformat}
> The error happens inside this implementation:
>
>
> {noformat}
> public void injectServices(ServiceRegistryImplementor serviceRegistry) {
> final Object dataSourceConfigValue = serviceRegistry.getService( ConfigurationService.class )
> .getSettings()
> .get( AvailableSettings.DATASOURCE );
> if ( dataSourceConfigValue == null || ! String.class.isInstance( dataSourceConfigValue ) ) {
> throw new HibernateException( "Improper set up of DataSourceBasedMultiTenantConnectionProviderImpl" );
> }
> ...{noformat}
> The changed behavior is that the the parameter is no longer a String, but a WildFlyDataSource.
>
> I'm opening this case just to check if this is the expected behavior, and I should really override the necessary part of the code in order to circumvent the error or was this some sort of regression?
> Kindly,
> Rafael Sampaio
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-11233) Allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-11233?page=com.atlassian.jira.plugi... ]
Scott Marlow resolved WFLY-11233.
---------------------------------
Resolution: Out of Date
resolving as out of date. If this becomes important again, please reopen.
> Allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.redhat.com/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> The use case is to reduce the cost of Hibernate EntityManager creation/initialization, which could be more expensive for certain applications that use Hibernate extensions to perform additional processing at EntityManager creation time.
> Details from JPA 2.2 specification:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> This jira will specifically address transaction-scoped persistence contexts referenced in JTA transactions, as there is a known point of when they are no longer referenced and can be returned to the EntityManager cache. EntityManagers that are SynchronizationType.UNSYNCHRONIZED, will not be cached.
> Persistence unit hint "wildfly.jpa.emcache", may be:
> * true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
> * false (default), no caching is performed.
> Persistence unit hint "wildfly.jpa.emcache.size", may be:
> * 0 (default), the cache (if enabled) is unbounded. Performance may be better than bounded but will consume more memory.
> * N, where N is the bounded cache max size of EntityManager instances. Bounded cache will consume less memory but may incur more performance overhead (e.g. likely to use a contended synchronization lock).
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-11233) Allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-11233?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-11233:
-------------------------------------
I'm going to close this issue for now.
> Allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.redhat.com/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> The use case is to reduce the cost of Hibernate EntityManager creation/initialization, which could be more expensive for certain applications that use Hibernate extensions to perform additional processing at EntityManager creation time.
> Details from JPA 2.2 specification:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> This jira will specifically address transaction-scoped persistence contexts referenced in JTA transactions, as there is a known point of when they are no longer referenced and can be returned to the EntityManager cache. EntityManagers that are SynchronizationType.UNSYNCHRONIZED, will not be cached.
> Persistence unit hint "wildfly.jpa.emcache", may be:
> * true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
> * false (default), no caching is performed.
> Persistence unit hint "wildfly.jpa.emcache.size", may be:
> * 0 (default), the cache (if enabled) is unbounded. Performance may be better than bounded but will consume more memory.
> * N, where N is the bounded cache max size of EntityManager instances. Bounded cache will consume less memory but may incur more performance overhead (e.g. likely to use a contended synchronization lock).
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-13714) JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13714?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13714:
-------------------------------------
{quote}
The vfs url should be resolved to a plain file or jar URL that actually exists on file system before passing the URL to a JPA provider when creating an EntityManagerFactory.
{quote}
[~java202020] sorry for the delay in responding. It has been around 10 years or so since I tried insulating the JPA providers from VFS but it wasn't a 1-1 mapping for all deployments.
Are you trying to use a custom persistence provider?
> JPA PersistenceUnitInfo.persistenceUnitRootUrl vfs URL should be resolved
> -------------------------------------------------------------------------
>
> Key: WFLY-13714
> URL: https://issues.redhat.com/browse/WFLY-13714
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 20.0.1.Final
> Reporter: Java Java
> Assignee: Scott Marlow
> Priority: Major
>
> Wildlfy passes a PersistenceUnitInfo object to JPA provider using vfs URL as persistenceUnitRootUrl, e.g.,
> vfs:/C:/wildfly-20.0.1.Final/bin/content/foo.ear/myejb.jar/
> A JPA provider can not resolve this URL without using a third-party library and thus force
> the JPA provider to have dependency on 3rd party libraries or wildfly.
>
> The vfs url should be resolved to a plain file or jar URL that actually exists on file system before passing the URL to a JPA provider when creating an EntityManagerFactory.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months