[JBoss JIRA] (WFLY-10619) Add version 7 of the management model for the Undertow subsystem
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10619?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10619:
------------------------------------
[~dlofthouse], [~kabirkhan] Just a curious question - I can see that new undertow model of version 7 has no difference when compared to version 6. What is actual reason for adding this? Is it just in advance change because of the planned changes? Normally I would expect that new model is introduced when there are some real changes in model so we avoid unnecessary version increments.
> Add version 7 of the management model for the Undertow subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-10619
> URL: https://issues.jboss.org/browse/WFLY-10619
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 14.0.0.CR1
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2281:
---------------------------
Description:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
was:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents up 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2281:
---------------------------
Description:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents up 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
was:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely no to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents up 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents up 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2657) [DMN Designer] Select Box for Decision Table input columns
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2657?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2657:
--------------------------------
Description:
Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
h3. Acceptance test
# Sorting in select box
# Rename InputData, change reflected in select box
# Same InputData connected to multiple nodes, appropriate select boxes contain the value
was:Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
> [DMN Designer] Select Box for Decision Table input columns
> ----------------------------------------------------------
>
> Key: DROOLS-2657
> URL: https://issues.jboss.org/browse/DROOLS-2657
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
> h3. Acceptance test
> # Sorting in select box
> # Rename InputData, change reflected in select box
> # Same InputData connected to multiple nodes, appropriate select boxes contain the value
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2657) [DMN Designer] Select Box for Decision Table input columns
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2657?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2657:
--------------------------------
Affects Version/s: 7.8.0.Final
> [DMN Designer] Select Box for Decision Table input columns
> ----------------------------------------------------------
>
> Key: DROOLS-2657
> URL: https://issues.jboss.org/browse/DROOLS-2657
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2657) [DMN Designer] Select Box for Decision Table input columns
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2657:
-----------------------------------
Summary: [DMN Designer] Select Box for Decision Table input columns
Key: DROOLS-2657
URL: https://issues.jboss.org/browse/DROOLS-2657
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Reporter: Jozef Marko
Assignee: Michael Anstis
Priority: Minor
Currently the decision table input columns can be named with any name. However their names should correspond to InputData elements in the DRG, thus we should provide select box for each decision table input column, where user would select corresponding InputData element for the given decision table input column.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2655) [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2655?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-2655:
-------------------------------------
[~uxdlc] I would like to ask you for help also in this jira. We are going to generate automatically some columns of decision table according to DataObject fields. However we have a problem/concern in case the data object will contain a lot of fields, lets say more than 5. In this case we do not want to generate columns automatically because the decision table will become disarranged. So I would like to ask you for your suggestion here. My idea is to show some tree (similar to upcoming scenarios) where user will select given fields, but not sure if it is the best approach.
> [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2655
> URL: https://issues.jboss.org/browse/DROOLS-2655
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> [~tari_manga] suggested it advantageous to create input columns for each {{InputData}} element linked to the {{Decision}}/{{BusinessKnowledgeModel}} containing the {{DecisionTable}} expression. For example, if a BKM has 2 {{InputData}} nodes of simple data-types then two columns should be created. If a BKM has 1 {{InputData}} node of complex data-type that consists of 3 elements then 3 columns should be created.
> - For simple data types the input column names should correspond exactly to InputData elements.
> - For complex data types, we should use dot notation, e.g. Person.name, Person.salary ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2655) [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2655?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2655:
--------------------------------
Description:
[~tari_manga] suggested it advantageous to create input columns for each {{InputData}} element linked to the {{Decision}}/{{BusinessKnowledgeModel}} containing the {{DecisionTable}} expression. For example, if a BKM has 2 {{InputData}} nodes of simple data-types then two columns should be created. If a BKM has 1 {{InputData}} node of complex data-type that consists of 3 elements then 3 columns should be created.
- For simple data types the input column names should correspond exactly to InputData elements.
- For complex data types, we should use dot notation, e.g. Person.name, Person.salary ...
was:
[~tari_manga] suggested it advantageous to create input columns for each {{InputData}} element linked to the {{Decision}}/{{BusinessKnowledgeModel}} containing the {{DecisionTable}} expression. For example, if a BKM has 2 {{InputData}} nodes of simple data-types then two columns should be created. If a BKM has 1 {{InputData}} node of complex data-type that consists of 3 elements then 3 columns should be created.
> [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2655
> URL: https://issues.jboss.org/browse/DROOLS-2655
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> [~tari_manga] suggested it advantageous to create input columns for each {{InputData}} element linked to the {{Decision}}/{{BusinessKnowledgeModel}} containing the {{DecisionTable}} expression. For example, if a BKM has 2 {{InputData}} nodes of simple data-types then two columns should be created. If a BKM has 1 {{InputData}} node of complex data-type that consists of 3 elements then 3 columns should be created.
> - For simple data types the input column names should correspond exactly to InputData elements.
> - For complex data types, we should use dot notation, e.g. Person.name, Person.salary ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months