[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10339 at 9/27/18 6:24 PM:
--------------------------------------------------------------
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups-supplied capability is required is not the same attribute that determines the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
was (Author: pferraro):
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10339:
-------------------------------------
[~jmesnil]
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}
I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.
AIUI, the complexity for provisioning is two-fold:
# The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.
We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.
> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
> Key: WFLY-10339
> URL: https://issues.jboss.org/browse/WFLY-10339
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Paul Ferraro
> Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-11088) Deployment failure if existing HA deployment contains a common EJB class
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-11088:
-----------------------------------
Summary: Deployment failure if existing HA deployment contains a common EJB class
Key: WFLY-11088
URL: https://issues.jboss.org/browse/WFLY-11088
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 14.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, the command dispatcher ID uses the bean name. This needs to be qualified using the deployment name.
{noformat}Thrown in org.wildfly.clustering.server.dispatcher.MangedCommandDispatcherFactory.cre>ateCommandDispatcher(Object id, C context) line 98 "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefullBean.START" => "java.lang.Ille galArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefullBean alrea dy exists, but with a different command context",
slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".component.StatefulBean2.START" => "java.lang.IllegalA rgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already exists, but with a different command context slave1 | [Server:group1] Caused by: java.lang.IllegalArgumentException: WFLYCLSV0017: A command dispatcher for StatefulBean2 already e xists, but with a different command context"
slave1 | [Server:group1] },
slave1 | [Server:group1] "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
slave1 | [Server:group1] "Services that were unable to start:" => [ slave1 | [Server:group1] "jboss.deployment.subunit.\"app2.ear\".\"app2.war\".moduleDeploymentRuntimeInformationStart", slave1 | [Server:group1] "jboss.deployment.unit.\"app2.ear\".WeldEndInitService", slave1 | [Server:group1] "jboss.undertow.deployment.default-server.default-host./app2"
slave1 | [Server:group1] ], slave1 | [Server:group1] "Services that may be the cause:" => `
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4139:
------------------------------------------
I understand now. The ProcessController has no shutdown hook, so calling Process.destroy on it is going to succeed very quickly. The HC process then detects the close of stdin and shuts down. So that is async to stopping the PC.
So maybe this is an Enhancement to make that better, or maybe just a Won't Fix because the chance of doing harm with a fix outweighs any benefit.
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4139) Unclean disconnect of stopping slave HC from the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4139?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4139:
-------------------------------------
Priority: Minor (was: Major)
> Unclean disconnect of stopping slave HC from the domain
> -------------------------------------------------------
>
> Key: WFCORE-4139
> URL: https://issues.jboss.org/browse/WFCORE-4139
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
> Labels: domain-mode
>
> An interesting problem popped up when executing a new test I wrote.[1]
> The test invoked DomainLifecycleUtil.stop() to stop the slave HC. After it returned, it invoked an op on the master, one that would result in domain wide rollout. That failed with a failure indicating a problem sending the op to the slave.
> But the slave should have been disconnected from the master before DomainLifecycleUtil.stop() returned. It does a process.stop() on the PC, which should cleanly stop the PC, which cleanly stops the HC, which should cleanly disconnect from the master as part of stopping. But somehow that didn't all happen.
> [1] These specific details will soon be out of date; i.e. I'll change the test to work around this and eventually the test job will come out of TeamCity history. But anyway here they are:
> https://ci.wildfly.org/viewLog.html?buildId=123039&tab=buildResultsDiv&bu...
> {code}
> java.lang.AssertionError: {"host-failure-descriptions" => {"slave" => "Writes closed"}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:229)
> at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.validateResponse(DomainTestSupport.java:221)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.addRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:189)
> at org.jboss.as.test.integration.domain.suites.HostLifecycleWithRolloutPlanTestCase.testSlaveBootWithMissingRolloutPlan(HostLifecycleWithRolloutPlanTestCase.java:167)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3000:
-------------------------------------
[~karreiro] p.s. I named the constraint "Simple" (although that seems a bit odd to me) because I haven't heard back from you or [~tirelli] as to whether this can be renamed or if it's part of the FEEL standard.
> Enhance data type restrictions UX (decision tables & DT dialog)
> ---------------------------------------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, date-time.png, date.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Liz Clayton edited comment on DROOLS-3000 at 9/27/18 2:27 PM:
--------------------------------------------------------------
[~karreiro] p.s. I named the constraint "Simple" (although that seems a bit odd to me) because I haven't heard back from you or [~tirelli] as to whether this can be renamed or if it's part of the FEEL standard or etc.
was (Author: uxdlc):
[~karreiro] p.s. I named the constraint "Simple" (although that seems a bit odd to me) because I haven't heard back from you or [~tirelli] as to whether this can be renamed or if it's part of the FEEL standard.
> Enhance data type restrictions UX (decision tables & DT dialog)
> ---------------------------------------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, date-time.png, date.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3000:
--------------------------------
Attachment: date-time.png
date.png
read-mode.png
time.png
> Enhance data type restrictions UX (decision tables & DT dialog)
> ---------------------------------------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, date-time.png, date.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months