[JBoss JIRA] (WFCORE-2930) Support a socket-binding-group as a child of profile
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2930?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2930:
-------------------------------
Fix Version/s: 5.0.0.Alpha3
(was: 5.0.0.Alpha2)
> Support a socket-binding-group as a child of profile
> ----------------------------------------------------
>
> Key: WFCORE-2930
> URL: https://issues.jboss.org/browse/WFCORE-2930
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 5.0.0.Alpha3
>
>
> Allow a single socket-binding-group resource as a child of profile, such that resolution of bindings from the subsystems are limited to the s-b-g associated with the profile.
> A server-group that uses such a profile cannot reference a socket-binding-group. And a server in that server-group cannot reference an s-b-g to override the one from the server-group/profile.
> I'm not sure how the s-b-g resource will work. Perhaps the resource would go away under 'profile' with the bindings direct children of profile. The 'default-interface' attribute then becomes an attribute of profile. Or perhaps there will be an s-b-g resource, but with a fixed name that's the same as the profile. Currently I think the latter.
> This will be necessary for resolution of config elements using the upcoming provisioning tool. The tool will not be able to do correct "feature" resolution using the complex rules we currently support.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1649:
-------------------------------
Fix Version/s: 5.0.0.Alpha3
(was: 5.0.0.Alpha2)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 5.0.0.Alpha3
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10020) Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10020?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10020:
-------------------------------------
We are working on integrating Hibernate ORM 5.3.0. I think that there was a pull request to integrate with ORM 5.2, that included some WF code changes but I think that is likely out of date now. We are jumping ahead to 5.3.0, for the JPA 2.2 support.
We merged some of the support (hibernate-jipijapa) into [https://github.com/hibernate/hibernate-orm] but not the 2lc support yet. [jpa22_orm53_5|https://github.com/scottmarlow/wildfly/tree/jpa22_orm53_5] is what I have been testing with (after building the Hibernate ORM master project locally).
There are also some other branches involved for refactoring the Infinispan second level cache integration that are showing progress but not yet integrated yet that is not really ready yet.
> Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-10020
> URL: https://issues.jboss.org/browse/WFLY-10020
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 12.0.0.Final
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
>
> Migrating to 12 with Hibernate Custom slot causes NullPointer Exception.
> https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2.13.Final" />
> 16:12:28,868 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for optoplus
> 16:12:29,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "optoplus-services-ear-1.0.18-SNAPSHOT.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.addCacheDependencies(InfinispanCacheDeploymentListener.java:129)
> at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.addCacheDependencies(CacheDeploymentListener.java:111)
> at org.jipijapa.event.impl.internal.Notification.addCacheDependencies(Notification.java:95)
> at org.jboss.as.jpa.hibernate5.HibernateSecondLevelCache.addSecondLevelCacheDependencies(HibernateSecondLevelCache.java:125)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(HibernatePersistenceProviderAdaptor.java:107)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:538)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:273)
> 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:144)
> ... 8 more
> 16:12:29,155 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"optoplus-services-ear-1.0.18-SNAPSHOT.ear\".FIRST_MODULE_USE" => "WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment \"optoplus-services-ear-1.0.18-SNAPSHOT.ear\"
> Caused by: java.lang.NullPointerException"}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3718) mvn versions:set -DnewVersion=xxxx does not replace component-matrix/pom.xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3718?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3718:
------------------------------------------
sed ftw!
> mvn versions:set -DnewVersion=xxxx does not replace component-matrix/pom.xml
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3718
> URL: https://issues.jboss.org/browse/WFCORE-3718
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 5.0.0.Alpha2
> Reporter: Kabir Khan
> Assignee: Tomaz Cerar
>
> {quote}
> [2:26 PM] Kabir Khan: @ctomc following https://developer.jboss.org/wiki/WildFlyCoreReleaseProcess, and using
> mvn versions:set -DnewVersion=5.0.0.Alpha2
> [2:26 PM] Kabir Khan: it seems to keep component-matrix/pom.xml as -SNAPSHOT
> [2:26 PM] Kabir Khan: $git grep "\-SNAPSHOT"
> component-matrix/pom.xml: <version>5.0.0.Alpha2-SNAPSHOT</version>
> [2:27 PM] Tomaz Cerar: damn, that is not good
> [2:27 PM] Tomaz Cerar: versions plugin is bit stupid in some cases
> [2:27 PM] Kabir Khan: Should it be in the list of modules?
> [2:27 PM] Tomaz Cerar: it is
> {quote}
> All other versions are correctly replaced. I'd hazard a guess that this also happens in WF full.
> CC [~brian.stansberry] - for the 5.0.0.Alpha2 release I'm using the old find/sed way
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-107) Openshift Cluster Allocation
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-107?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-107:
-------------------------------------
I would suggest to use for only b17 and above for production cluster. Those are PowerEdge R620 which are certified with RHEL 7.x [1] Older blades < b16 are PowerEdge c6100 which are not certified and somebody from sys-ops noted that it might be problematic to run there RHEL 7.4+
[1] - https://access.redhat.com/ecosystem/hardware/948323
> Openshift Cluster Allocation
> ----------------------------
>
> Key: SWSQE-107
> URL: https://issues.jboss.org/browse/SWSQE-107
> Project: Swift Sunshine QE
> Issue Type: QE Task
> Reporter: Matt Mahoney
> Assignee: Matt Mahoney
>
> We now have (3) Openshift clusters, for which we will want to define use allocation for each (aka: how will these cluster be used).
> On one of these clusters, we will want to have our 'Production' CI pipeline.
> b21 -> Currently general usage for pipeline automation and manual testing
> b12 -> Newly created, and unused
> b11 -> Newly created, and unused
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9975) infinispan cache-container[jndi-name] fails validation in WildFly 12
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-9975?page=com.atlassian.jira.plugin.... ]
Alessandro Moscatelli commented on WFLY-9975:
---------------------------------------------
I used "java:jboss/infinispan/container/hibernate" where "hibernate" is the name of the cache-container:
<cache-container name="hibernate" default-cache="local-query" module="org.infinispan.hibernate-cache">
somehow this seems to be correct ...
> infinispan cache-container[jndi-name] fails validation in WildFly 12
> --------------------------------------------------------------------
>
> Key: WFLY-9975
> URL: https://issues.jboss.org/browse/WFLY-9975
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 12.0.0.Final
> Environment: ALL
> Reporter: Pratik Parikh
> Assignee: Jason Greene
> Priority: Blocker
>
> Widfly 12 fails to recognize jndi-name attribute and emits exception the following:
> OPVDX001: Validation error in standalone.xml -----------------------------------
> |
> | 336:
> | 337:
> | 338:
> | ^^^^ 'jndi-name' isn't an allowed attribute for the 'cache-container'
> | element
> |
> | Attributes allowed here are:
> | aliases jndi-name name
> | default-cache module statistics-enabled
> |
> | 339:
> | 340:
> | 341:
> |
> | 'jndi-name' is allowed on elements:
> | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > context-services > context-service
> | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-thread-factories > managed-thread-factory
> | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-executor-services > managed-executor-service
> | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-scheduled-executor-services > managed-scheduled-executor-service
> | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container
> | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > local-cache
> | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > replicated-cache
> | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > invalidation-cache
> | - server > profile > {urn:jboss:domain:mail:3.0}subsystem > mail-session
> | - server > profile > {urn:jboss:domain:transactions:4.0}subsystem > commit-markable-resources > commit-markable-resource
> |
> |
> | The primary underlying error message was:
> | > ParseError at [row,col]:[338,4]
> | > Message: WFLYCTL0197: Unexpected attribute 'jndi-name' encountered
> |
> |-------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10020) Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-10020?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli commented on WFLY-10020:
----------------------------------------------
This is as far as I can go :(
java.util.ServiceConfigurationError: org.hibernate.boot.registry.selector.StrategyRegistrationProvider: Provider org.infinispan.hibernate.cache.StrategyRegistrationProviderImpl not a subtype
> Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-10020
> URL: https://issues.jboss.org/browse/WFLY-10020
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 12.0.0.Final
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
>
> Migrating to 12 with Hibernate Custom slot causes NullPointer Exception.
> https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2.13.Final" />
> 16:12:28,868 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for optoplus
> 16:12:29,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "optoplus-services-ear-1.0.18-SNAPSHOT.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.addCacheDependencies(InfinispanCacheDeploymentListener.java:129)
> at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.addCacheDependencies(CacheDeploymentListener.java:111)
> at org.jipijapa.event.impl.internal.Notification.addCacheDependencies(Notification.java:95)
> at org.jboss.as.jpa.hibernate5.HibernateSecondLevelCache.addSecondLevelCacheDependencies(HibernateSecondLevelCache.java:125)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(HibernatePersistenceProviderAdaptor.java:107)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:538)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:273)
> 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:144)
> ... 8 more
> 16:12:29,155 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"optoplus-services-ear-1.0.18-SNAPSHOT.ear\".FIRST_MODULE_USE" => "WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment \"optoplus-services-ear-1.0.18-SNAPSHOT.ear\"
> Caused by: java.lang.NullPointerException"}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10020) Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-10020?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli commented on WFLY-10020:
----------------------------------------------
I spent the whole day trying every possible combination and nothing works.
Documentation is outdated so :
could you please prove a tested combination and configuration of wildfly 12 + custom hibernate orm modules ?
At the top I can read "Wildfly 11"
https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules
Is this even supposed to work with Wildfly 12 ? Is this too soon ?
> Custom Hibernate slot and second level cache with Wildfly 12 causes NullPointer Exception
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-10020
> URL: https://issues.jboss.org/browse/WFLY-10020
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 12.0.0.Final
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
>
> Migrating to 12 with Hibernate Custom slot causes NullPointer Exception.
> https://mvnrepository.com/artifact/org.hibernate/hibernate-orm-modules
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2.13.Final" />
> 16:12:28,868 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for optoplus
> 16:12:29,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."optoplus-services-ear-1.0.18-SNAPSHOT.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "optoplus-services-ear-1.0.18-SNAPSHOT.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.addCacheDependencies(InfinispanCacheDeploymentListener.java:129)
> at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.addCacheDependencies(CacheDeploymentListener.java:111)
> at org.jipijapa.event.impl.internal.Notification.addCacheDependencies(Notification.java:95)
> at org.jboss.as.jpa.hibernate5.HibernateSecondLevelCache.addSecondLevelCacheDependencies(HibernateSecondLevelCache.java:125)
> at org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(HibernatePersistenceProviderAdaptor.java:107)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:538)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:273)
> 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:144)
> ... 8 more
> 16:12:29,155 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"optoplus-services-ear-1.0.18-SNAPSHOT.ear\".FIRST_MODULE_USE" => "WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment \"optoplus-services-ear-1.0.18-SNAPSHOT.ear\"
> Caused by: java.lang.NullPointerException"}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2260) UNICAST3 doesn't remove dead nodes from its tables
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2260?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2260:
--------------------------------
I created ForkChannelTest.testSimpleSend(). Take a look at it, especially at around line 104ff. I observed that the retransmission to the non-existent B ceases after ~1 minute.
> UNICAST3 doesn't remove dead nodes from its tables
> --------------------------------------------------
>
> Key: JGRP-2260
> URL: https://issues.jboss.org/browse/JGRP-2260
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: WildFly 12.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Bela Ban
>
> Scenario: 2 WildFly instances clustered together. A ForkChannel is defined, with a MessageDispatcher on top. I start both nodes, then stop the second one. 6-7 minutes after stopping the second node, I start getting log spam on the first node:
> {quote}
> 12:47:04,519 WARN [org.jgroups.protocols.UDP] (TQ-Bundler-4,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) JGRP000032: RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null): no physical address for RCD_NMS (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null), dropping message
> 12:47:06,522 WARN [org.jgroups.protocols.UDP] (TQ-Bundler-4,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) JGRP000032: RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null): no physical address for RCD_NMS (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null), dropping message
> 12:47:08,524 WARN [org.jgroups.protocols.UDP] (TQ-Bundler-4,ee,RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null)) JGRP000032: RCD_GP (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null): no physical address for RCD_NMS (flags=0), site-id=DEFAULT, rack-id=null, machine-id=null), dropping message
> {quote}
> After some debugging, I discovered that the reason is because UNICAST3 is still trying to retransmit to the dead node. Its send_table still contains an entry for the dead node with state OPEN.
> After looking at the source code for UNICAST3, I have a theory about what's happening.
> * When a node leaves the cluster, down(Event) gets invoked with a view change, which calls closeConnection(Address) for each node that left. That sets the connection state to CLOSING.
> * Suppose that immediately after the view change is handled, a message with the dead node as its destination gets passed to down(Message). That invokes getSenderEntry(Address), which finds the connection... and sets the state back to OPEN.
> Consequently, the connection is never closed or removed from the table, so retransmit attempts continue forever even though they will never succeed.
> This issue is easily reproducible for me, although unfortunately I can't give you the application in question. But if you have fixes you want to try, I'm happy to drop in a patched JAR and see if the issue still happens.
> This is my JGroups subsystem configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
> <channels default="ee">
> <channel name="ee" stack="main">
> <fork name="shared-dispatcher"/>
> <fork name="group-topology"/>
> </channel>
> </channels>
> <stacks>
> <stack name="main">
> <transport type="UDP" socket-binding="jgroups" site="${gp.site:DEFAULT}"/>
> <protocol type="PING"/>
> <protocol type="MERGE3">
> <property name="min_interval">
> 1000
> </property>
> <property name="max_interval">
> 5000
> </property>
> </protocol>
> <protocol type="FD_SOCK"/>
> <protocol type="FD_ALL2">
> <property name="interval">
> 3000
> </property>
> <property name="timeout">
> 8000
> </property>
> </protocol>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS">
> <property name="join_timeout">
> 100
> </property>
> </protocol>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG3"/>
> </stack>
> </stacks>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month