[JBoss JIRA] (DROOLS-3207) [DMN Designer] Cell/header selection improvements
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3207?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3207:
-----------------------------------
Tester: Jozef Marko
Labels: drools-tools (was: )
> [DMN Designer] Cell/header selection improvements
> -------------------------------------------------
>
> Key: DROOLS-3207
> URL: https://issues.jboss.org/browse/DROOLS-3207
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.13.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Headers and cells can now be selected however there is some inconsistency to their behaviour.
> It is possible to select a header cell first and then a body cell with {{ctrl}} pressed and both remain selected. If however you select first a body cell and then a header cell with {{ctrl}} pressed the body cell becomes deselected (this is because {{HeaderSingleCellSelectionStrategy}} clears the models selections).
> Also, following changes for "drill down" {{LiteralExpressionGrid}} and {{UndefinedExpressionGrid}} "act on their own" regarding selection. i.e. create a {{Context}} and add a new {{ContextEntry}} setting its {{Expression}} to a {{LiteralExpression}}. Select multiple cells with {{ctrl}} and when the {{LiteralExpressionGrid}} and {{UndefindExpressionGrid}} cells' are selected the {{Context}} cells become deselected. Ideally the parent cell selections should change too so they _appear_ to be visually selected together.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3207) [DMN Designer] Cell/header selection improvements
by Michael Anstis (Jira)
Michael Anstis created DROOLS-3207:
--------------------------------------
Summary: [DMN Designer] Cell/header selection improvements
Key: DROOLS-3207
URL: https://issues.jboss.org/browse/DROOLS-3207
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Affects Versions: 7.13.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
Headers and cells can now be selected however there is some inconsistency to their behaviour.
It is possible to select a header cell first and then a body cell with {{ctrl}} pressed and both remain selected. If however you select first a body cell and then a header cell with {{ctrl}} pressed the body cell becomes deselected (this is because {{HeaderSingleCellSelectionStrategy}} clears the models selections).
Also, following changes for "drill down" {{LiteralExpressionGrid}} and {{UndefinedExpressionGrid}} "act on their own" regarding selection. i.e. create a {{Context}} and add a new {{ContextEntry}} setting its {{Expression}} to a {{LiteralExpression}}. Select multiple cells with {{ctrl}} and when the {{LiteralExpressionGrid}} and {{UndefindExpressionGrid}} cells' are selected the {{Context}} cells become deselected. Ideally the parent cell selections should change too so they _appear_ to be visually selected together.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4190?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFCORE-4190:
-------------------------------------
When the microprofile-metrics-smallrye extension will register MP metrics from WildFly metrics, it will ignore (and not expose from its HTTP endpoints) any metric that returns an undefined value.
> Distinguish undefined metric value
> ----------------------------------
>
> Key: WFCORE-4190
> URL: https://issues.jboss.org/browse/WFCORE-4190
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
> Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
> When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
> This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
> Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
> When the metric is defined[2], it specifies an undefined metric value of 0.
> From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
> * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
> * statistics-enabled is true but there is no network traffic on the HTTP listener
> These 2 cases are wildly different but it is not possible to distinguish between them
> In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
> This parameter is taken into account only for metric attribute:
> * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
> * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
> This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
> When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
> These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
> [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
> [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
> [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
> [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFCORE-4190) Distinguished undefined metric value
by Jeff Mesnil (Jira)
Jeff Mesnil created WFCORE-4190:
-----------------------------------
Summary: Distinguished undefined metric value
Key: WFCORE-4190
URL: https://issues.jboss.org/browse/WFCORE-4190
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 7.0.0.Alpha4
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
When the metric is defined[2], it specifies an undefined metric value of 0.
>From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
* the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
* statistics-enabled is true but there is no network traffic on the HTTP listener
These 2 cases are wildly different but it is not possible to distinguish between them
In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
This parameter is taken into account only for metric attribute:
* if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
* if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
[1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
[2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
[3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
[4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4190?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4190:
--------------------------------
Summary: Distinguish undefined metric value (was: Distinguished undefined metric value)
> Distinguish undefined metric value
> ----------------------------------
>
> Key: WFCORE-4190
> URL: https://issues.jboss.org/browse/WFCORE-4190
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
>
> WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
> Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
> When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
> This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
> Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
> When the metric is defined[2], it specifies an undefined metric value of 0.
> From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
> * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
> * statistics-enabled is true but there is no network traffic on the HTTP listener
> These 2 cases are wildly different but it is not possible to distinguish between them
> In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
> This parameter is taken into account only for metric attribute:
> * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
> * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
> This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
> When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
> These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
> [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
> [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
> [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
> [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4190?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4190:
--------------------------------
Priority: Critical (was: Major)
> Distinguish undefined metric value
> ----------------------------------
>
> Key: WFCORE-4190
> URL: https://issues.jboss.org/browse/WFCORE-4190
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
> Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
> When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
> This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
> Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
> When the metric is defined[2], it specifies an undefined metric value of 0.
> From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
> * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
> * statistics-enabled is true but there is no network traffic on the HTTP listener
> These 2 cases are wildly different but it is not possible to distinguish between them
> In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
> This parameter is taken into account only for metric attribute:
> * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
> * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
> This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
> When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
> These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
> [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
> [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
> [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
> [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11255) EE Concurrency Utilities Managed Executors / Thread Pool runtime stats
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-11255:
-----------------------------------
Summary: EE Concurrency Utilities Managed Executors / Thread Pool runtime stats
Key: WFLY-11255
URL: https://issues.jboss.org/browse/WFLY-11255
Project: WildFly
Issue Type: Feature Request
Components: EE
Affects Versions: 14.0.0.Final
Reporter: Brad Maxwell
The managed executors / thread pools in the EE subsytem currently do not show any runtime information when invoked with include-runtime=true, the current thread pool size, queue length and such would be useful to check the performance and tuning.
{code}
/subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
{
"outcome" => "success",
"result" => {
"context-service" => "default",
"core-threads" => undefined,
"hung-task-threshold" => 60000L,
"jndi-name" => "java:jboss/ee/concurrency/executor/default",
"keepalive-time" => 5000L,
"long-running-tasks" => false,
"max-threads" => undefined,
"queue-length" => undefined,
"reject-policy" => "ABORT",
"thread-factory" => undefined
}
}
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3193:
-------------------------------------
[~tirelli] Thanks, good to know. Given that, then is the capability to order/reorder columns a compliment functionality? [~kkufova] Do we have that now, if not is there a jira for that? Likewise is there support for reordering rows?
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months