[JBoss JIRA] (DROOLS-4424) [DMN Designer] Copy of BKM node throws an error
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-4424?page=com.atlassian.jira.plug... ]
Valentino Pellegrino reassigned DROOLS-4424:
--------------------------------------------
Assignee: Valentino Pellegrino (was: Guilherme Gomes)
> [DMN Designer] Copy of BKM node throws an error
> -----------------------------------------------
>
> Key: DROOLS-4424
> URL: https://issues.redhat.com/browse/DROOLS-4424
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.25.0.Final, 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Valentino Pellegrino
> Priority: Major
> Labels: drools-tools
> Fix For: 7.37.0.Final
>
> Attachments: Screenshot from 2019-08-12 09-31-02.png
>
>
> User can create a diagram node copy by standard key compination *Ctrl+C* and *Ctrl+V*. The issue is if a BKM node is copied in this way. Then if user navigates into expression editor of the copied node there are two issues:
> # The content is not copied
> # Any attempt to define an expression type throws an error, see the attachement
> h2. Acceptance test
> https://github.com/kiegroup/kie-wb-common/pull/3272
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-2222) Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-2222?page=com.atlassian.jira.plug... ]
Valentino Pellegrino resolved DROOLS-2222.
------------------------------------------
Tester: Jozef Marko
Fix Version/s: 7.37.0.Final
Resolution: Done
> Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
> -------------------------------------------------------------------
>
> Key: DROOLS-2222
> URL: https://issues.redhat.com/browse/DROOLS-2222
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor, Stunner
> Reporter: Michael Anstis
> Assignee: Valentino Pellegrino
> Priority: Major
> Fix For: 7.37.0.Final
>
>
> As discussed on DROOLS-2214 Stunner needs to support (or provide extension points) for DMN's "copy/paste" of a {{Node}} to also deep-clone the definition. Please either (a) use this JIRA to record any changes needed in Stunner, (b) provide an explanation of how DMN can override the copy/paste to deep-clone definitions. Thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-2222) Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
by Valentino Pellegrino (Jira)
[ https://issues.redhat.com/browse/DROOLS-2222?page=com.atlassian.jira.plug... ]
Valentino Pellegrino reassigned DROOLS-2222:
--------------------------------------------
Assignee: Valentino Pellegrino (was: Tiago Dolphine)
> Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
> -------------------------------------------------------------------
>
> Key: DROOLS-2222
> URL: https://issues.redhat.com/browse/DROOLS-2222
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor, Stunner
> Reporter: Michael Anstis
> Assignee: Valentino Pellegrino
> Priority: Major
>
> As discussed on DROOLS-2214 Stunner needs to support (or provide extension points) for DMN's "copy/paste" of a {{Node}} to also deep-clone the definition. Please either (a) use this JIRA to record any changes needed in Stunner, (b) provide an explanation of how DMN can override the copy/paste to deep-clone definitions. Thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4948) read-resource operation does not return the version and name spaces
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFCORE-4948?page=com.atlassian.jira.plug... ]
Yeray Borges Santana resolved WFCORE-4948.
------------------------------------------
Resolution: Rejected
Rejected as it is working as expected.
The result returned on 6.0.0.Final was indeed an incorrect result because the returned information belongs to runtime attributes that should not be displayed by default by the {{read-resource}} operation. It was fixed by WFCORE-4183.
The following operation returns the expected information:
{noformat}
[standalone@localhost:9990 /] /extension=org.jboss.as.jmx/subsystem=jmx:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"management-major-version" => 1,
"management-micro-version" => 0,
"management-minor-version" => 2,
"xml-namespaces" => [
"urn:jboss:domain:jmx:1.0",
"urn:jboss:domain:jmx:1.1",
"urn:jboss:domain:jmx:1.2",
"urn:jboss:domain:jmx:1.3"
]
}
}
{noformat}
> read-resource operation does not return the version and name spaces
> -------------------------------------------------------------------
>
> Key: WFCORE-4948
> URL: https://issues.redhat.com/browse/WFCORE-4948
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Final
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
>
> The following operation, in this case for the jmx subsystem resource, returns the version and xml-namespaces of the read resource:
> {noformat}
> [standalone@localhost:9990 /] /extension=org.jboss.as.jmx/subsystem=jmx:read-resource
> {
> "outcome" => "success",
> "result" => {
> "management-major-version" => 1,
> "management-micro-version" => 0,
> "management-minor-version" => 2,
> "xml-namespaces" => [
> "urn:jboss:domain:jmx:1.0",
> "urn:jboss:domain:jmx:1.1",
> "urn:jboss:domain:jmx:1.2",
> "urn:jboss:domain:jmx:1.3"
> ]
> }
> }
> {noformat}
> Since wildlfly-core 7.0.0.Final, this operation does not return any value:
> {noformat}
> [standalone@localhost:9990 /] /extension=org.jboss.as.jmx/subsystem=jmx:read-resource
> {
> "outcome" => "success",
> "result" => {}
> }
> {noformat}
> The operation returns the same empty result for any subsystem read similarly under the extension resource.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2135:
---------------------------
Fix Version/s: 3.6.20.Final
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12, 3.6.20.Final
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2135.
----------------------------
Resolution: Done
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.20.Final, 3.6.12
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2135:
--------------------------------
Actually, I'm going to release a {{3.6.20.Final}}.
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years