[JBoss JIRA] (DROOLS-2349) [DMN Editor] Decision Navigator dock
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2349?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2349:
--------------------------------
Description:
The "Decision Navigator" is docked next to the Project Explorer. See:
!prototype.png|thumbnail!
- Tree navigation offers a view of the entire DRG. Diagram nodes are represented within the tree.
- User defined DRD’s are represented as top level tree nodes, with supporting decision and input data represented as subordinate tree nodes.
- Tree structure only goes as deep as primary logic definition, such as a decision table (nested logic is not represented in the tree.)
- The Navigator includes a preview image which represents a thumbnail view of the diagram view selected.
h2. Acceptance tests
h3. Prerequisite
Prepare non empty DRD diagram, specify expressions in decisions, ensure DRG contains all node types
# Check node icons (/)
## expression types distinguished
h3. Expand / Collapse
# check that expand / collapse shows always all elements, doesn't change order between expanding/collapsing (/)
# check situation when multiple nodes has the same name, empty name (/)
## same names no problem, empty name replace with node type, nice
# Check case when DRG contains a lot of nodes , if possible to view all of them (/)
## scrollbar appears, and disappear according to count of nodes, nice
# Check case when some decision has a lot of inputs - all of them visible (/)
h3. Full screen mode
# check behavior of navigator when DMN designer is used in full screen mode (x)
## DROOLS-2431 - does not prevent from merge
# Check if navigator dock can be resized (/)
h3. Navigation
# check *back to* link present if DRD opened and shows proper node name (/)
# check click in Navigator dock cause either selecting DRG node or opening given DRD
## opened DRG, clicked other DRG node (/)
## opened DRG, clicked DRD (x)
### DROOLS-2432 does not prevent from merge
## opened DRD, clicked other DRD (/)
## opened DRD, clicked DRG node (/)
# Check behavior if user tries to select multiple entries in navigator (/)
## not implemented, but fine, no exception
# Check behavior if user tries to invoke context menu from navigator (/)
## not implemented, but fine, no exception
# Check behavior if user tries to drag some elements in navigator (/)
## not implemented, but fine, no exception
h3. Sorting
# nodes sorted asc, changes in node names reflected in order (/)
# rename some DRG nodes, check navigator keeps selected sorting (/)
h3. Undo / Redo
# change selection in navigator, check behavior of undo redo (x)
## DROOLS-2433
# rename some DRG nodes, undo redo, check changes reflected in navigator (/)
# delete DRG node, undo redo, check changes reflected in navigator (/)
# clear DRD node, undo redo, check changes reflected in navigator (x)
## DROOLS-2434
h3. Synchronization
# delete DRG node, check changes reflected in navigator (/)
# clear DRD node, check changes reflected in navigator (x)
## DROOLS-2434
# Drag DRG elements, no effect to expected (/)
# Rebuild connections, change should appear in navigator (?)
## not checked, because not able to connect DRG nodes
# Check multiple connections, input node connected to multiple decisions ... (?)
## not checked, because not able to connect DRG nodes
# Long node names (/) perfect
# Changes in DRD, navigate to other DRG node, other DRD, then return to first DRD, check changes present without saving (x)
## DROOLS-2435
was:
The "Decision Navigator" is docked next to the Project Explorer. See:
!prototype.png|thumbnail!
- Tree navigation offers a view of the entire DRG. Diagram nodes are represented within the tree.
- User defined DRD’s are represented as top level tree nodes, with supporting decision and input data represented as subordinate tree nodes.
- Tree structure only goes as deep as primary logic definition, such as a decision table (nested logic is not represented in the tree.)
- The Navigator includes a preview image which represents a thumbnail view of the diagram view selected.
h2. Acceptance tests
h3. Prerequisite
Prepare non empty DRD diagram, specify expressions in decisions, ensure DRG contains all node types
# Check node icons (/)
## expression types distinguished
h3. Expand / Collapse
# check that expand / collapse shows always all elements, doesn't change order between expanding/collapsing (/)
# check situation when multiple nodes has the same name, empty name (/)
## same names no problem, empty name replace with node type, nice
# Check case when DRG contains a lot of nodes , if possible to view all of them (/)
## scrollbar appears, and disappear according to count of nodes, nice
# Check case when some decision has a lot of inputs - all of them visible (?)
## not checked, because not able to connect DRG nodes
h3. Full screen mode
# check behavior of navigator when DMN designer is used in full screen mode (x)
## DROOLS-2431 - does not prevent from merge
# Check if navigator dock can be resized (/)
h3. Navigation
# check *back to* link present if DRD opened and shows proper node name (/)
# check click in Navigator dock cause either selecting DRG node or opening given DRD
## opened DRG, clicked other DRG node (/)
## opened DRG, clicked DRD (x)
### DROOLS-2432 does not prevent from merge
## opened DRD, clicked other DRD (/)
## opened DRD, clicked DRG node (/)
# Check behavior if user tries to select multiple entries in navigator (/)
## not implemented, but fine, no exception
# Check behavior if user tries to invoke context menu from navigator (/)
## not implemented, but fine, no exception
# Check behavior if user tries to drag some elements in navigator (/)
## not implemented, but fine, no exception
h3. Sorting
# nodes sorted asc, changes in node names reflected in order (/)
# rename some DRG nodes, check navigator keeps selected sorting (/)
h3. Undo / Redo
# change selection in navigator, check behavior of undo redo (x)
## DROOLS-2433
# rename some DRG nodes, undo redo, check changes reflected in navigator (/)
# delete DRG node, undo redo, check changes reflected in navigator (/)
# clear DRD node, undo redo, check changes reflected in navigator (x)
## DROOLS-2434
h3. Synchronization
# delete DRG node, check changes reflected in navigator (/)
# clear DRD node, check changes reflected in navigator (x)
## DROOLS-2434
# Drag DRG elements, no effect to expected (/)
# Rebuild connections, change should appear in navigator (?)
## not checked, because not able to connect DRG nodes
# Check multiple connections, input node connected to multiple decisions ... (?)
## not checked, because not able to connect DRG nodes
# Long node names (/) perfect
# Changes in DRD, navigate to other DRG node, other DRD, then return to first DRD, check changes present without saving (x)
## DROOLS-2435
> [DMN Editor] Decision Navigator dock
> ------------------------------------
>
> Key: DROOLS-2349
> URL: https://issues.jboss.org/browse/DROOLS-2349
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Attachments: prototype.png
>
>
> The "Decision Navigator" is docked next to the Project Explorer. See:
> !prototype.png|thumbnail!
> - Tree navigation offers a view of the entire DRG. Diagram nodes are represented within the tree.
> - User defined DRD’s are represented as top level tree nodes, with supporting decision and input data represented as subordinate tree nodes.
> - Tree structure only goes as deep as primary logic definition, such as a decision table (nested logic is not represented in the tree.)
> - The Navigator includes a preview image which represents a thumbnail view of the diagram view selected.
> h2. Acceptance tests
> h3. Prerequisite
> Prepare non empty DRD diagram, specify expressions in decisions, ensure DRG contains all node types
> # Check node icons (/)
> ## expression types distinguished
> h3. Expand / Collapse
> # check that expand / collapse shows always all elements, doesn't change order between expanding/collapsing (/)
> # check situation when multiple nodes has the same name, empty name (/)
> ## same names no problem, empty name replace with node type, nice
> # Check case when DRG contains a lot of nodes , if possible to view all of them (/)
> ## scrollbar appears, and disappear according to count of nodes, nice
> # Check case when some decision has a lot of inputs - all of them visible (/)
> h3. Full screen mode
> # check behavior of navigator when DMN designer is used in full screen mode (x)
> ## DROOLS-2431 - does not prevent from merge
> # Check if navigator dock can be resized (/)
> h3. Navigation
> # check *back to* link present if DRD opened and shows proper node name (/)
> # check click in Navigator dock cause either selecting DRG node or opening given DRD
> ## opened DRG, clicked other DRG node (/)
> ## opened DRG, clicked DRD (x)
> ### DROOLS-2432 does not prevent from merge
> ## opened DRD, clicked other DRD (/)
> ## opened DRD, clicked DRG node (/)
> # Check behavior if user tries to select multiple entries in navigator (/)
> ## not implemented, but fine, no exception
> # Check behavior if user tries to invoke context menu from navigator (/)
> ## not implemented, but fine, no exception
> # Check behavior if user tries to drag some elements in navigator (/)
> ## not implemented, but fine, no exception
> h3. Sorting
> # nodes sorted asc, changes in node names reflected in order (/)
> # rename some DRG nodes, check navigator keeps selected sorting (/)
> h3. Undo / Redo
> # change selection in navigator, check behavior of undo redo (x)
> ## DROOLS-2433
> # rename some DRG nodes, undo redo, check changes reflected in navigator (/)
> # delete DRG node, undo redo, check changes reflected in navigator (/)
> # clear DRD node, undo redo, check changes reflected in navigator (x)
> ## DROOLS-2434
> h3. Synchronization
> # delete DRG node, check changes reflected in navigator (/)
> # clear DRD node, check changes reflected in navigator (x)
> ## DROOLS-2434
> # Drag DRG elements, no effect to expected (/)
> # Rebuild connections, change should appear in navigator (?)
> ## not checked, because not able to connect DRG nodes
> # Check multiple connections, input node connected to multiple decisions ... (?)
> ## not checked, because not able to connect DRG nodes
> # Long node names (/) perfect
> # Changes in DRD, navigate to other DRG node, other DRD, then return to first DRD, check changes present without saving (x)
> ## DROOLS-2435
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10173?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-10173:
------------------------------
Description:
Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0)
{code}
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
[ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
...
{code}
was:
Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0.
For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0)
{code}
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
[ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
...
{code}
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.jboss.org/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Jan Kalina (JIRA)
Jan Kalina created WFLY-10173:
---------------------------------
Summary: EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
Key: WFLY-10173
URL: https://issues.jboss.org/browse/WFLY-10173
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 12.0.0.Final
Reporter: Jan Kalina
Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0.
For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0)
{code}
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
[ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
...
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment in CLI batch with audit logging enabled
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda updated WFCORE-695:
-------------------------------------
Description:
When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text).
Comment by Alexey: Bytes are attached only when deploy command is used in CLI batches. Otherwise, it's streams.
Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
{code}
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
{code}
A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
was:
When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
> OutOfMemoryErrors when adding large deployment in CLI batch with audit logging enabled
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text).
> Comment by Alexey: Bytes are attached only when deploy command is used in CLI batches. Otherwise, it's streams.
> Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> {code}
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment in CLI batch with audit logging enabled
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda updated WFCORE-695:
-------------------------------------
Summary: OutOfMemoryErrors when adding large deployment in CLI batch with audit logging enabled (was: OutOfMemoryErrors when adding large deployment with audit logging enabled)
> OutOfMemoryErrors when adding large deployment in CLI batch with audit logging enabled
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2425) [DMN Designer] Undo of relation column deletion is not proper
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2425?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-2425:
-------------------------------------
[~manstis] will try to add more details what I will test, however often I decide after I see touched code.
> [DMN Designer] Undo of relation column deletion is not proper
> -------------------------------------------------------------
>
> Key: DROOLS-2425
> URL: https://issues.jboss.org/browse/DROOLS-2425
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 12-12-05.png, Screenshot from 2018-03-27 12-14-47.png, Screenshot from 2018-03-27 12-14-55.png
>
>
> This issue was spotted during DROOLS-2392 review.
> In special cases undo of delete relation column is not proper.
> h2. Acceptance test
> # Steps to reproduce fixed (/)
> # Deletion is undone properly
> ## Deletion of con. entry (/)
> ## Deletion of Dec. table row (/)
> ## Deletion of Dec. table column (x)
> ## Deletion of Relation column
> ## Deletion of Relation row
> ## Deletion of Function parameter
> # Clear of expression type is undone properly
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2425) [DMN Designer] Undo of relation column deletion is not proper
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2425?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2425:
----------------------------------------
[~jomarko] For JIRA you raise it would not hurt to include details of what you'd be testing.. then I can be sure PRs are complete.
I feel I have recently wasted a lot of your time (with the "column width" issue) when, although I think it is fixed, you all too easily find issues.
> [DMN Designer] Undo of relation column deletion is not proper
> -------------------------------------------------------------
>
> Key: DROOLS-2425
> URL: https://issues.jboss.org/browse/DROOLS-2425
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Attachments: Screenshot from 2018-03-27 12-12-05.png, Screenshot from 2018-03-27 12-14-47.png, Screenshot from 2018-03-27 12-14-55.png
>
>
> This issue was spotted during DROOLS-2392 review.
> In special cases undo of delete relation column is not proper.
> h2. Acceptance test
> # Steps to reproduce fixed (/)
> # Deletion is undone properly
> ## Deletion of con. entry (/)
> ## Deletion of Dec. table row (/)
> ## Deletion of Dec. table column (x)
> ## Deletion of Relation column
> ## Deletion of Relation row
> ## Deletion of Function parameter
> # Clear of expression type is undone properly
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months