[JBoss JIRA] (WFLY-9276) client-mappings cache dropping entries and breaking EJB client cluster membership correctness
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-9276?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-9276:
--------------------------------------
Description:
Copied from JBEAP-12889:
{quote}
The EJB client relies on topology updates from servers in order to maintain a view of cluster membership. These updates are supplied with membership information by a replicated cache called the client-mappings cache. When a server starts up, it puts a client-mappings entry into this cache. When topology changes occur, the client mappings cache entries are consulted to build the topology update information.
It has been observed that the number of entries in the client mappings cache on each node can vary, resulting in different views of the cluster topology being sent by different servers to the same client, resulting in an overall incorrect view of the cluster topology. Such incorrect views break load balancing.
{quote}
was:
Copied from JBEAP-12889:
{noformat}
The EJB client relies on topology updates from servers in order to maintain a view of cluster membership. These updates are supplied with membership information by a replicated cache called the client-mappings cache. When a server starts up, it puts a client-mappings entry into this cache. When topology changes occur, the client mappings cache entries are consulted to build the topology update information.
It has been observed that the number of entries in the client mappings cache on each node can vary, resulting in different views of the cluster topology being sent by different servers to the same client, resulting in an overall incorrect view of the cluster topology. Such incorrect views break load balancing.
{noformat}
> client-mappings cache dropping entries and breaking EJB client cluster membership correctness
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9276
> URL: https://issues.jboss.org/browse/WFLY-9276
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> Copied from JBEAP-12889:
> {quote}
> The EJB client relies on topology updates from servers in order to maintain a view of cluster membership. These updates are supplied with membership information by a replicated cache called the client-mappings cache. When a server starts up, it puts a client-mappings entry into this cache. When topology changes occur, the client mappings cache entries are consulted to build the topology update information.
> It has been observed that the number of entries in the client mappings cache on each node can vary, resulting in different views of the cluster topology being sent by different servers to the same client, resulting in an overall incorrect view of the cluster topology. Such incorrect views break load balancing.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9276) client-mappings cache dropping entries and breaking EJB client cluster membership correctness
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-9276:
-----------------------------------------
Summary: client-mappings cache dropping entries and breaking EJB client cluster membership correctness
Key: WFLY-9276
URL: https://issues.jboss.org/browse/WFLY-9276
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.CR1
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Copied from JBEAP-12889:
{noformat}
The EJB client relies on topology updates from servers in order to maintain a view of cluster membership. These updates are supplied with membership information by a replicated cache called the client-mappings cache. When a server starts up, it puts a client-mappings entry into this cache. When topology changes occur, the client mappings cache entries are consulted to build the topology update information.
It has been observed that the number of entries in the client mappings cache on each node can vary, resulting in different views of the cluster topology being sent by different servers to the same client, resulting in an overall incorrect view of the cluster topology. Such incorrect views break load balancing.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-6149) Improve control over 'hibernate.id.new_generator_mappings' setting
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6149?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6149:
------------------------------------
>From a discussion in the [Hibernate ORM Dev Hipchat room|https://www.hipchat.com/gDZHRKgWN], I heard that Hibernate ORM is looking into having system properties take precedence over the persistence.xml settings.
> Improve control over 'hibernate.id.new_generator_mappings' setting
> ------------------------------------------------------------------
>
> Key: WFLY-6149
> URL: https://issues.jboss.org/browse/WFLY-6149
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Chris Poulsen
>
> It would be great if Wildfly offered better control over the properties used for configuring persistence units.
> For instance the 'hibernate.id.new_generator_mappings' setting has proven hard to control it currently requires one to change persistence.xml to turn it off.
> Hibernate supports specifying the properties in various ways, for example via system properties, but wildfly forces the new mappings to be enabled unless the persistence.xml says to disable them.
> There are some suggestions to how [~smarlow] imagines this to be implemented in the forum thread: https://developer.jboss.org/thread/267613
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Eduardo Martins edited comment on WFCORE-3205 at 8/29/17 12:08 PM:
-------------------------------------------------------------------
There are several use cases regarding logging (User code uses JBoss Logging? Class loading uses JBoss Modules?) and the Embedded Process has to support all so I think it's going to be though to don't require any configuration. The Migration Tool uses JBoss Logging in its code, and using that system package arg the embedded server logging works fine with (tool integrated in server dist) and without (tool standalone dist) JBoss Modules.
Perhaps ensure it works without config when user code does not uses JBoss Logging, and keep config possibilities for other user cases?
was (Author: emmartins):
There are several use cases regarding logging (User code uses JBoss Logging? Class loading uses JBoss Modules?) and the Embedded Process has to support all so I think it's going to be though to don't require any configuration. The Migration Tool uses JBoss Logging in its code, and using that system package arg the embedded server logging works fine with and without JBoss Modules.
Perhaps ensure it works without config when user code does not uses JBoss Logging, and keep config possibilities for other user cases?
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Eduardo Martins edited comment on WFCORE-3205 at 8/29/17 12:05 PM:
-------------------------------------------------------------------
There are several use cases regarding logging (User code uses JBoss Logging? Class loading uses JBoss Modules?) and the Embedded Process has to support all so I think it's going to be though to don't require any configuration. The Migration Tool uses JBoss Logging in its code, and using that system package arg the embedded server logging works fine with and without JBoss Modules.
Perhaps ensure it works without config when user code does not uses JBoss Logging, and keep config possibilities for other user cases?
was (Author: emmartins):
There are several use cases regarding logging (User code uses JBoss Logging? Class loading uses JBoss Modules?) and the Embedded Process has to support all so I think it's going to be though to don't require any configuration. The Migration Tool uses JBoss Logging in its code, and using that system package arg the embedded server logging works fine with and without JBoss Modules.
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Eduardo Martins commented on WFCORE-3205:
-----------------------------------------
There are several use cases regarding logging (User code uses JBoss Logging? Class loading uses JBoss Modules?) and the Embedded Process has to support all so I think it's going to be though to don't require any configuration. The Migration Tool uses JBoss Logging in its code, and using that system package arg the embedded server logging works fine with and without JBoss Modules.
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3205:
---------------------------------------
[~emmartins] IMO a user shouldn't have to configure the log manager in order for the embedded server to work. In most cases I would guess that the embedded server is not being launched in a modular environment. That is one of the main issues and why the log manager gets loaded twice on the class path. Adding it to the system package would only work in a modular environment.
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3205:
---------------------------------------
[~ge0ffrey] Currently excluding the jboss-logmanager dependency would likely be the easiest solution. The only other solution I can think of would require changes before the the embedded server is started. Offline CLI does this and it's really kind of complex IMO.
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Giovanni Lovato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Giovanni Lovato commented on WFLY-9053:
---------------------------------------
Thank you [~sannegrinovero] for the update. Just to make this clear: the exception reported by this issue happens when ORM 5.2 modules are unpacked as described at https://docs.jboss.org/hibernate/orm/5.2/topical/html_single/wildfly/Wild... in WildFly 11. I see in your PR that only the classifier has changed, thus not resolving the exception. Maybe another PR is involved?
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero closed WFLY-9053.
---------------------------------
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months