[JBoss JIRA] (WFLY-11275) JSF ViewMap Regression
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11275?page=com.atlassian.jira.plugin... ]
Cody Lerum commented on WFLY-11275:
-----------------------------------
Also filed https://github.com/eclipse-ee4j/mojarra/issues/4509
> JSF ViewMap Regression
> ----------------------
>
> Key: WFLY-11275
> URL: https://issues.jboss.org/browse/WFLY-11275
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.1.Final
> Environment: Java 8
> Wildfly 14.0.1
> Reporter: Cody Lerum
> Assignee: Farah Juma
> Priority: Major
>
> I'm been running into an occasional NPE in production with JSF after migrating from Wildfly 11 to Wildfly 14.0.1 ( Mojarra 2.2.13.SP4 -> 2.3.5.SP2 ) and I believe I've tracked down a small demo project that duplicates the issue. I've set the project to JSF 2.2 so it will deploy on both WF 11 and WF 14.
> The basic problem is that when two pages with the same view id are loaded in separate tabs. From there is one of the tabs is posted and the result navigates to a different view id all references to that view id are removed from the view map. If the post does not navigate to a different view id then all works normally.
> My assumption is that when the post navigates away to a new view id any reference to any page with the same view id is removed from the view map. This did not occur in Wildfly 11.
> Additional clue is that even though the viewmap reference is removed the view scoped beans referencing it are not destroyed.
> Demo project at https://github.com/codylerum/demos/tree/ee7/jsf-npe
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11275) JSF ViewMap Regression
by Cody Lerum (Jira)
[ https://issues.jboss.org/browse/WFLY-11275?page=com.atlassian.jira.plugin... ]
Cody Lerum updated WFLY-11275:
------------------------------
Description:
I'm been running into an occasional NPE in production with JSF after migrating from Wildfly 11 to Wildfly 14.0.1 ( Mojarra 2.2.13.SP4 -> 2.3.5.SP2 ) and I believe I've tracked down a small demo project that duplicates the issue. I've set the project to JSF 2.2 so it will deploy on both WF 11 and WF 14.
The basic problem is that when two pages with the same view id are loaded in separate tabs. From there is one of the tabs is posted and the result navigates to a different view id all references to that view id are removed from the view map. If the post does not navigate to a different view id then all works normally.
My assumption is that when the post navigates away to a new view id any reference to any page with the same view id is removed from the view map. This did not occur in Wildfly 11.
Additional clue is that even though the viewmap reference is removed the view scoped beans referencing it are not destroyed.
Demo project at https://github.com/codylerum/demos/tree/ee7/jsf-npe
was:
I'm been running into an occasional NPE in production with JSF after migrating from Wildfly 11 to Wildfly 14.0.1 and I believe I've tracked down a small demo project that duplicates the issue. I've set the project to JSF 2.2 so it will deploy on both WF 11 and WF 14.
The basic problem is that when two pages with the same view id are loaded in separate tabs. From there is one of the tabs is posted and the result navigates to a different view id all references to that view id are removed from the view map. If the post does not navigate to a different view id then all works normally.
My assumption is that when the post navigates away to a new view id any reference to any page with the same view id is removed from the view map. This did not occur in Wildfly 11.
Additional clue is that even though the viewmap reference is removed the view scoped beans referencing it are not destroyed.
Demo project at https://github.com/codylerum/demos/tree/ee7/jsf-npe
> JSF ViewMap Regression
> ----------------------
>
> Key: WFLY-11275
> URL: https://issues.jboss.org/browse/WFLY-11275
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.1.Final
> Environment: Java 8
> Wildfly 14.0.1
> Reporter: Cody Lerum
> Assignee: Farah Juma
> Priority: Major
>
> I'm been running into an occasional NPE in production with JSF after migrating from Wildfly 11 to Wildfly 14.0.1 ( Mojarra 2.2.13.SP4 -> 2.3.5.SP2 ) and I believe I've tracked down a small demo project that duplicates the issue. I've set the project to JSF 2.2 so it will deploy on both WF 11 and WF 14.
> The basic problem is that when two pages with the same view id are loaded in separate tabs. From there is one of the tabs is posted and the result navigates to a different view id all references to that view id are removed from the view map. If the post does not navigate to a different view id then all works normally.
> My assumption is that when the post navigates away to a new view id any reference to any page with the same view id is removed from the view map. This did not occur in Wildfly 11.
> Additional clue is that even though the viewmap reference is removed the view scoped beans referencing it are not destroyed.
> Demo project at https://github.com/codylerum/demos/tree/ee7/jsf-npe
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11277) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
Scott Marlow created WFLY-11277:
-----------------------------------
Summary: allow EntityManager caching in the JPA container
Key: WFLY-11277
URL: https://issues.jboss.org/browse/WFLY-11277
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Reporter: Scott Marlow
Assignee: Scott Marlow
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{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}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
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.
* N, where N is the max number of EntityManager instances that can be placed in the EntityManagerCache, in between application use.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{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}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
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.
* N, where N is the max number of EntityManager instances that can be placed in the EntityManagerCache, in between application use.
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{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}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
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.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {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}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
> For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
> 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.
> * N, where N is the max number of EntityManager instances that can be placed in the EntityManagerCache, in between application use.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Yeray Borges commented on WFLY-5966:
------------------------------------
Just for the record, these removals were done in https://issues.jboss.org/browse/WFLY-11165
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> The following modules were fixed or verified as correct (moved from the first list):
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{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}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
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.
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{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}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache.
We currently keep strong references to the (cleared) EntityManager's from the cache. If this causes OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions.
Code changes will likely be:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places. Not Implemented yet.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
* Also ensure that SynchronizationType is respected, so we don't mix SynchronizationType.UNSYNCHRONIZED + SynchronizationType.SYNCHRONIZED types. We will only cache SynchronizationType.SYNCHRONIZED.
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.
To ensure that we always put the cached EM back in cache, cache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {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}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
> For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
> 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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11198) Session draining on stopped worker won't complete if further requests are made on balancer
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11198?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11198:
---------------------------------------
[~jkasik] Please rerun the test with debug logs on mod_cluster and upload the logs, this way it will be clearer if the problem is in the draining logic or session expiry logic.
> Session draining on stopped worker won't complete if further requests are made on balancer
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11198
> URL: https://issues.jboss.org/browse/WFLY-11198
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 15.0.0.Alpha1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Major
>
> When disabling worker with {{/subsystem=modcluster/proxy=default:stop(waittime=0)}}, the contexts are switched to {{disabled}} state. If there no further requests (on the same context which session currently times out) are made on a balancer, session correctly times out, contexts switch to {{stopped}} state and everything is OK.
> However, when I run same stop operation, wait until contexts are switched into {{disabled}} state and in time in which sessions time out I make more requests on balancer, contexts will never switch to {{stopped}} state and session draining never completes. This happens intermittently (~60% of cases with 10 requests made after {{disabled}} state is in place).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11265) wildfly-feature-pack -- Dependency Error
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11265?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFLY-11265.
-------------------------------------
Resolution: Rejected
I'm going to reject this as I don't see what else we could do about this. Our dependency-management specifies that javax.security.enterprise:javax.security.enterprise-api:1.0 should be used.
> wildfly-feature-pack -- Dependency Error
> ----------------------------------------
>
> Key: WFLY-11265
> URL: https://issues.jboss.org/browse/WFLY-11265
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 14.0.0.Final
> Environment: Ubuntu 18.10
> JDK 11
> WildFly 14.0.1.Final
> Reporter: Dennis Gesker
> Assignee: Jason Greene
> Priority: Major
> Labels: wildfly-feature-pack
> Fix For: 14.0.0.Final
>
>
> In my gradle build I've added:
> * providedCompile "org.wildfly:wildfly-feature-pack:14.0.1.Final"*
>
> But, I'm getting:
>
> *> Could not resolve javax.security.enterprise:javax.security.enterprise-api:1.1-b01-SNAPSHOT.
> Required by:
> project : > org.wildfly:wildfly-feature-pack:14.0.1.Final > org.glassfish.soteria:javax.security.enterprise:1.0*
> > Could not resolve javax.security.enterprise:javax.security.enterprise-api:1.1-b01-SNAPSHOT.
> > Unable to load Maven meta-data from https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu....
> > Could not get resource 'https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu...'.
> > Could not GET 'https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu...'.
> > extension (10) should not be presented in server_hello
>
> Presently I have the following repositories in my build:
>
> jcenter()
> mavenCentral()
>
> maven {
> name "Gradle Repository"
> url "https://plugins.gradle.org/m2/"
> }
> maven {
> name "JBoss Public Maven Repository Group"
> url "https://repository.jboss.org/nexus/content/groups/public-jboss/"
> }
> maven {
> name "JBoss Public Maven Repository Group"
> url "http://repository.jboss.org/nexus/content/groups/public/"
> }
>
>
> But, I suspect I am missing a repository specific to WildFly. Or, maybe there is a bad entry in the POM?
>
> Thanks,
> Dennis
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11259?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-11259:
-------------------------------------
Also, please check with WildFly 14 as well.
> Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11259
> URL: https://issues.jboss.org/browse/WFLY-11259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Adam Bialas
> Assignee: Scott Marlow
> Priority: Major
>
> I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown:
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> and the application fails to deploy.
> I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used.
> I created jboss-deployment-structure:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.dom4j"/>
> </exclusions>
> </deployment>
> </jboss-deployment-structure>
> Even though I get the same exception so I suppose both jars are loaded and cause problems.
> I checked how class loading works on Wildfly 11.0.0 in comparison to JBoss EAP 7.1. In both cases this class is first loaded from provided 1.6.1 jar. JBoss does not load the newer version. However, Wildfly does and here is the problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0
[JBoss JIRA] (DROOLS-3054) Highlight in expression builder previous selection in Scenario right panel
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3054?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi closed DROOLS-3054.
------------------------------------
Resolution: Done
Implemented inside https://issues.jboss.org/browse/DROOLS-3095
> Highlight in expression builder previous selection in Scenario right panel
> --------------------------------------------------------------------------
>
> Key: DROOLS-3054
> URL: https://issues.jboss.org/browse/DROOLS-3054
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UX-CSS, UXTeam
> Attachments: RightPanel.png, RightPanel.png, Screen Shot 2018-09-28 at 3.45.25 PM.png, Screen Shot 2018-10-15 at 1.38.30 PM.png, Screen Shot 2018-10-18 at 2.51.59 PM.png, Screenshot from 2018-10-12 15-53-50.png, Screenshot from 2018-10-18 17-58-35.png, Screenshot from 2018-10-19 08-59-20.png, TestEditorTree.mp4, tree-issues.png, tree.png
>
>
> When the user edits the type of a column, the expression builder into the right panel should highlight the existing mapped type.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
- 1
- 0