[JBoss JIRA] (JGRP-2451) FD_ALL2: improvements
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2451:
---------------------------
Description:
Improvements to {{FD_ALL2}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
* There's a map associating members with booleans. True means a heartbeat was received since the last check, false means it wasn't. On a check, the booleans are all set to false.
It is crucial that setting the in the map is quick (not like in {{FD_ALL}}, where we fetch the current time from the time service), especially since this is done on every message.
The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
was:
New heartbeat protocol, based on {{FD_ALL2}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be default, and as such, deprecated).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
* A simple bitmap represents members: bits set to {{1}} mean we received a heartbeat since the last check (at {{timeout}} ms), bits set to {{0}} lead to suspicions
* The bitmap is reset on each check
It is crucial that setting a bit in the bitmap is quick (not like in {{FD_ALL}}, where we fetch the current time from the time service), especially since this is done on every message.
The advantage of {{FD_ALL3}} over previous failure detection protocols is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
> FD_ALL2: improvements
> ---------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> Improvements to {{FD_ALL2}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> * There's a map associating members with booleans. True means a heartbeat was received since the last check, false means it wasn't. On a check, the booleans are all set to false.
> It is crucial that setting the in the map is quick (not like in {{FD_ALL}}, where we fetch the current time from the time service), especially since this is done on every message.
> The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
> However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2451) FD_ALL2: improvements
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2451:
---------------------------
Summary: FD_ALL2: improvements (was: FD_ALL3)
> FD_ALL2: improvements
> ---------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> New heartbeat protocol, based on {{FD_ALL2}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be default, and as such, deprecated).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> * A simple bitmap represents members: bits set to {{1}} mean we received a heartbeat since the last check (at {{timeout}} ms), bits set to {{0}} lead to suspicions
> * The bitmap is reset on each check
> It is crucial that setting a bit in the bitmap is quick (not like in {{FD_ALL}}, where we fetch the current time from the time service), especially since this is done on every message.
> The advantage of {{FD_ALL3}} over previous failure detection protocols is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
> However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5060) [DMN Designer] Editor allows node with prefix/trailing space
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5060?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5060:
----------------------------------------
Same comment applies as per: https://issues.redhat.com/browse/DROOLS-5062?focusedCommentId=13972166&pa...
> [DMN Designer] Editor allows node with prefix/trailing space
> ------------------------------------------------------------
>
> Key: DROOLS-5060
> URL: https://issues.redhat.com/browse/DROOLS-5060
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * -While Importing a DMN model from file Upload- (See [DROOLS-5062|https://issues.redhat.com/browse/DROOLS-5062])
> * While editing a DRGElement and hitting OK to save its name
> For your consideration, thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Systematically correct node prefix/trailing space on import
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5062:
----------------------------------------
Let's not muddle our JIRA... this JIRA represents the systematic application of fixes to a file after it is imported/opened.
Point of entry cleaning of {{DRGElement.Name}} and {{ItemDefinition.Name}} is handled by https://issues.redhat.com/browse/DROOLS-5060!
> [DMN Designer] Systematically correct node prefix/trailing space on import
> --------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * While Importing a DMN model from file Upload
> * -While editing a DRGElement and hitting OK to save its name- (See [DROOLS-5060|https://issues.redhat.com/browse/DROOLS-5060])
> For your consideration, thanks.
> See [comment|https://issues.redhat.com/browse/DROOLS-5060?focusedCommentId=139...] on DROOLS-5060:-
> {quote}
> I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
> * It is an automated correction/cleanse
> * We already have one automated correction (when layout information is missing or insufficient)
> * We may, in the future, want to support other automated corrections
> * I'd therefore like to consolidate the approach to how automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Systematically correct node prefix/trailing space on import
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5062 at 2/14/20 8:12 AM:
-----------------------------------------------------------------
We are lenient going AGAINST the principles of the spec, but we do it on the engine to avoid blowing up for a simple mistake like a trailing (superflous) space.
Frankly, this was a "smart" decision which we started to kind of regret on the engine side, as it's difficult to maintain and difficult to mitigate the impact on performance.
The spec in DMNv1.x is space-insensitive, and that's a fact.
So I would learn from our own mistake here, and doesn't make sense to name a node
{code:java}
"my decision "
{code}
or
{code:java}
"my decision "
{code}
and I would have any name corrected by the editor as
{code:java}
"my decision"
{code}
That said, clearly this must allow the user to input after introducing a space, so I'm NOT obviously saying that after entering
{code:java}
"my decision "
{code}
it would become
{code:java}
"mydecision"
{code}
I hope this is not misunderstood :)
Finally bonus point for normalizing spaces such as:
{code:java}
" my decision "
{code}
becoming again
{code:java}
"my decision"
{code}
How about instead of relying on our own perspective, we ask for a UX "experiment" --which however should take into account the context, in this specific case what is the principles of the DMN spec? ;)
ps: in this comment, the double quote is only used to denote the beginning and end of the name
was (Author: tari_manga):
We are lenient going AGAINST the principles of the spec, but we do it on the engine to avoid blowing up for a simple mistake like a trailing (superflous) space.
Frankly, this was a "smart" decision which we started to kind of regret on the engine side, as it's difficult to maintain and difficult to mitigate the impact on performance.
The spec in DMNv1.x is space-insensitive, and that's a fact.
So I would learn from our own mistake here, and doesn't make sense to name a node
{code:java}
"my decision "
{code}
or
{code:java}
"my decision "
{code}
and I would have any name corrected by the editor as
{code:java}
"my decision"
{code}
That said, clearly this must allow the user to input after introducing a space, so I'm NOT obviously saying that after entering
{code:java}
"my decision "
{code}
it would become
{code:java}
"mydecision"
{code}
I hope this is not misunderstood :)
Finally bonus point for normalizing spaces such as:
{code:java}
" my decision "
{code}
becoming again
{code:java}
"my decision"
{code}
How about instead of relying on our own perspective, we ask for a UX "experiment" --which however should take into account the context, in this specific case what is the principles of the DMN spec? ;)
> [DMN Designer] Systematically correct node prefix/trailing space on import
> --------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * While Importing a DMN model from file Upload
> * -While editing a DRGElement and hitting OK to save its name- (See [DROOLS-5060|https://issues.redhat.com/browse/DROOLS-5060])
> For your consideration, thanks.
> See [comment|https://issues.redhat.com/browse/DROOLS-5060?focusedCommentId=139...] on DROOLS-5060:-
> {quote}
> I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
> * It is an automated correction/cleanse
> * We already have one automated correction (when layout information is missing or insufficient)
> * We may, in the future, want to support other automated corrections
> * I'd therefore like to consolidate the approach to how automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Systematically correct node prefix/trailing space on import
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5062:
----------------------------------------
We are lenient going AGAINST the principles of the spec, but we do it on the engine to avoid blowing up for a simple mistake like a trailing (superflous) space.
Frankly, this was a "smart" decision which we started to kind of regret on the engine side, as it's difficult to maintain and difficult to mitigate the impact on performance.
The spec in DMNv1.x is space-insensitive, and that's a fact.
So I would learn from our own mistake here, and doesn't make sense to name a node
{code:java}
"my decision "
{code}
or
{code:java}
"my decision "
{code}
and I would have any name corrected by the editor as
{code:java}
"my decision"
{code}
That said, clearly this must allow the user to input after introducing a space, so I'm NOT obviously saying that after entering
{code:java}
"my decision "
{code}
it would become
{code:java}
"mydecision"
{code}
I hope this is not misunderstood :)
Finally bonus point for normalizing spaces such as:
{code:java}
" my decision "
{code}
becoming again
{code:java}
"my decision"
{code}
How about instead of relying on our own perspective, we ask for a UX "experiment" --which however should take into account the context, in this specific case what is the principles of the DMN spec? ;)
> [DMN Designer] Systematically correct node prefix/trailing space on import
> --------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * While Importing a DMN model from file Upload
> * -While editing a DRGElement and hitting OK to save its name- (See [DROOLS-5060|https://issues.redhat.com/browse/DROOLS-5060])
> For your consideration, thanks.
> See [comment|https://issues.redhat.com/browse/DROOLS-5060?focusedCommentId=139...] on DROOLS-5060:-
> {quote}
> I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
> * It is an automated correction/cleanse
> * We already have one automated correction (when layout information is missing or insufficient)
> * We may, in the future, want to support other automated corrections
> * I'd therefore like to consolidate the approach to how automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Systematically correct node prefix/trailing space on import
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5062:
-----------------------------------
Summary: [DMN Designer] Systematically correct node prefix/trailing space on import (was: [DMN Designer] Automatically correct node prefix/trailing space on import)
> [DMN Designer] Systematically correct node prefix/trailing space on import
> --------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * While Importing a DMN model from file Upload
> * -While editing a DRGElement and hitting OK to save its name- (See [DROOLS-5060|https://issues.redhat.com/browse/DROOLS-5060])
> For your consideration, thanks.
> See [comment|https://issues.redhat.com/browse/DROOLS-5060?focusedCommentId=139...] on DROOLS-5060:-
> {quote}
> I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
> * It is an automated correction/cleanse
> * We already have one automated correction (when layout information is missing or insufficient)
> * We may, in the future, want to support other automated corrections
> * I'd therefore like to consolidate the approach to how automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5062) [DMN Designer] Automatically correct node prefix/trailing space on import
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5062?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5062:
----------------------------------------
[~karreiro] Hehe.. well, this JIRA came from 7.33.0.Final testing.. those _using_ the editor found it annoying that whitespace was retained.
This JIRA represents the systematic modification to the file when it is imported/opened. Two such known operations:
# Apply layout of nodes if layout information is missing
# Remote leading/trailing white-space from Names/ItemDefinitions
The proposal being that a popup is shown to the user listing possible "fixes" and they select those they want to apply....
> [DMN Designer] Automatically correct node prefix/trailing space on import
> -------------------------------------------------------------------------
>
> Key: DROOLS-5062
> URL: https://issues.redhat.com/browse/DROOLS-5062
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: ItemDefinition-white-space.png
>
>
> I understand [DROOLS-5017] has been re-purposed to allow Info and Warn level messages be displayed on Stunner Validation dialog. That is fine.
> But, imho, an UX point is not being considered, where is necessary instead.
> By the DMN spec, a node should not have a prefix/trailing space, as space insensitivity would mandate 1 trailing or 2 trailing spaces are simply ignored etc.
> The engine is lenient to avoid this crashing the evaluation, but still is a bad designed model to persist the node name (DRGElement name and its corresponding variable name) with those extra spaces IMHO.
> Further, I consider is just the Analyst which slipped a space.
> In my perspective, the editor should just strip away the prefix/trailing space:
> * While Importing a DMN model from file Upload
> * -While editing a DRGElement and hitting OK to save its name- (See [DROOLS-5060|https://issues.redhat.com/browse/DROOLS-5060])
> For your consideration, thanks.
> See [comment|https://issues.redhat.com/browse/DROOLS-5060?focusedCommentId=139...] on DROOLS-5060:-
> {quote}
> I'd like to move the other request ("While Importing a DMN model from file Upload") to a new JIRA for the following reason:
> * It is an automated correction/cleanse
> * We already have one automated correction (when layout information is missing or insufficient)
> * We may, in the future, want to support other automated corrections
> * I'd therefore like to consolidate the approach to how automated corrections are detected, ran and reported to the User. My initial opinion is that when opening (or importing or some other trigger to be determined) a DMN file we collect (probably via CDI discovery) all implementations of "Automated Fixers" (one of which if layout another is trim leading/trailing space etc). We then show the list of possible fixes to the User, they can select whatever they like and then we run them and save the file. Anyway, IMO, it's out of scope of this JIRA as it'd need some UX involvement.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months