[JBoss JIRA] (DROOLS-3061) [DMN Designer] Automatic Layout Feature
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3061?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos updated DROOLS-3061:
-------------------------------------------
Description:
DMN Designer should *autolayout* new imported DMN models. The *autolayout* should position DRG diagram nodes into horizontal layers to minimize crossing of connectors with respect of *Top-Down* importance. It means if nodes *Layer B* are inputs for nodes in *Layer A* then the *Layer B* will be below *Layer A*. The *autolayout* should also try to minimize scrolling needed to see whole DRG diagram.
User should also have possibility to invoke *autolayout* feature any time during designing the diagram. In this case the action should be undoable with the *Undo* toolbar button.
The approach used to achieve this is the Sugiyama Method, which is done in 4 steps. Each step have its own set of algorithms. For each step, we selected one of the available algorithms to implement, based on our current needs and time to develop:
*Step 1 - Cycle breaking:* We break cycles in diagram by reversing some edges (they are de-reversed in the end). This step are required because we need ending points in step 2 while sweeping through graph;
*Step 2 - Layering:* We sweep through graph (diagram) and put each node (vertex) in a layer, based on it's distance from others node. For edges that crosses multiple layers, we create virtual vertices connecting those. They are removed at the end.
This approach usually puts the start nodes at the top and the deepest nodes at the end. In the current implementation we're using Longest Path algorithm. A better approach can be developed in future using Network Simplex;
*Step 3 - Node Ordering:* We order each node (vertex) inside its layers in order to reduce crossing, using median. Another approach that can be used is barycenter.
*Step 4 - Node Positioning:* We de-reverse nodes reversed in step 1 and remove virtual nodes reconnecting the concrete nodes. Then we calculate the position of each node. This step can be divided in two steps: one for horizontal position and other for vertical for better positioning. Currently we're using a simple approach: every block of nodes inside the layers is centered and the distance between layers is the same. So it will produce results like the attachment "Automatic Layout Demo".
was:
DMN Designer should *autolayout* new imported DMN models. The *autolayout* should position DRG diagram nodes into horizontal layers to minimize crossing of connectors with respect of *Top-Down* importance. It means if nodes *Layer B* are inputs for nodes in *Layer A* then the *Layer B* will be below *Layer A*. The *autolayout* should also try to minimize scrolling needed to see whole DRG diagram.
User should also have possibility to invoke *autolayout* feature any time during designing the diagram. In this case the action should be undoable with the *Undo* toolbar button.
The approach used to achieve this is the Sugiyama Method, which is done in 4 steps. Each step have its own algorithm:
*Step 1 - Cycle breaking:* We break cycles in diagram by reversing some edges (they are de-reversed in the end). This step are required because we need ending points in step 2 while sweeping through graph;
*Step 2 - Layering:* We sweep through graph (diagram) and put each node (vertex) in a layer, based on it's distance from others node. This approach usually puts the start nodes at the top and the deepest nodes at the end. In the current implementation we're using Longest Path algorithm. A better approach can be developed in future using Network Simplex;
*Step 3 - Node Ordering:* We order each node (vertex) inside its layers in order to reduce crossings;
*Step 4 - Node Positioning:* We calculate the position of each node. This step can be divided in two steps: one for horizontal position and other for vertical
> [DMN Designer] Automatic Layout Feature
> ---------------------------------------
>
> Key: DROOLS-3061
> URL: https://issues.jboss.org/browse/DROOLS-3061
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> DMN Designer should *autolayout* new imported DMN models. The *autolayout* should position DRG diagram nodes into horizontal layers to minimize crossing of connectors with respect of *Top-Down* importance. It means if nodes *Layer B* are inputs for nodes in *Layer A* then the *Layer B* will be below *Layer A*. The *autolayout* should also try to minimize scrolling needed to see whole DRG diagram.
> User should also have possibility to invoke *autolayout* feature any time during designing the diagram. In this case the action should be undoable with the *Undo* toolbar button.
> The approach used to achieve this is the Sugiyama Method, which is done in 4 steps. Each step have its own set of algorithms. For each step, we selected one of the available algorithms to implement, based on our current needs and time to develop:
> *Step 1 - Cycle breaking:* We break cycles in diagram by reversing some edges (they are de-reversed in the end). This step are required because we need ending points in step 2 while sweeping through graph;
> *Step 2 - Layering:* We sweep through graph (diagram) and put each node (vertex) in a layer, based on it's distance from others node. For edges that crosses multiple layers, we create virtual vertices connecting those. They are removed at the end.
> This approach usually puts the start nodes at the top and the deepest nodes at the end. In the current implementation we're using Longest Path algorithm. A better approach can be developed in future using Network Simplex;
> *Step 3 - Node Ordering:* We order each node (vertex) inside its layers in order to reduce crossing, using median. Another approach that can be used is barycenter.
> *Step 4 - Node Positioning:* We de-reverse nodes reversed in step 1 and remove virtual nodes reconnecting the concrete nodes. Then we calculate the position of each node. This step can be divided in two steps: one for horizontal position and other for vertical for better positioning. Currently we're using a simple approach: every block of nodes inside the layers is centered and the distance between layers is the same. So it will produce results like the attachment "Automatic Layout Demo".
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11103) If ServletInputStream.isReady returns false it is illegal to call the ServletInputStream.read method and EAP returns HTTP 200
by Adam Krajcik (Jira)
[ https://issues.jboss.org/browse/WFLY-11103?page=com.atlassian.jira.plugin... ]
Adam Krajcik moved JBEAP-15567 to WFLY-11103:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11103 (was: JBEAP-15567)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: 14.0.1.Final
(was: 7.2.0.CD14)
> If ServletInputStream.isReady returns false it is illegal to call the ServletInputStream.read method and EAP returns HTTP 200
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11103
> URL: https://issues.jboss.org/browse/WFLY-11103
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final
> Reporter: Adam Krajcik
> Assignee: Romain Pelisse
> Priority: Major
> Attachments: JBEAP-12223.zip
>
>
> EAP returns HTTP 200 instead of 500 when IllegalStateException is thrown if ServletInputStream.isReady returns false.
> This exists in 7.2.0.CD14, it works in 7.2.0.CD13.
> {code}
> Caused by: java.lang.IllegalStateException: UT010035: Stream in async mode was not ready for IO operation
> at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:164)
> at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:154)
> at org.resteasy.simple.deployment.er2.ResourceInfoInjectionResource$1.onDataAvailable(ResourceInfoInjectionResource.java:42)
> at io.undertow.servlet.spec.ServletContextImpl$3.call(ServletContextImpl.java:188)
> at io.undertow.servlet.spec.ServletContextImpl$3.call(ServletContextImpl.java:185)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.spec.ServletContextImpl.invokeOnDataAvailable(ServletContextImpl.java:1009)
> ... 4 more
> 16:27:16,509 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default I/O-5) RESTEASY002020: Unhandled asynchronous exception, sending back 500: org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: java.lang.IllegalStateException: UT010035: Stream in async mode was not ready for IO operation
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:257)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:197)
> at org.jboss.resteasy.core.SynchronousDispatcher.asynchronousExceptionDelivery(SynchronousDispatcher.java:513)
> at org.jboss.resteasy.core.AbstractAsynchronousResponse.internalResume(AbstractAsynchronousResponse.java:228)
> at org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse.resume(Servlet3AsyncHttpRequest.java:118)
> at org.resteasy.simple.deployment.er2.ResourceInfoInjectionResource$1.onError(ResourceInfoInjectionResource.java:61)
> at io.undertow.servlet.spec.ServletInputStreamImpl$ServletInputStreamChannelListener$1.run(ServletInputStreamImpl.java:317)
> at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:181)
> at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:178)
> at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1027)
> at io.undertow.servlet.spec.ServletInputStreamImpl$ServletInputStreamChannelListener.handleEvent(ServletInputStreamImpl.java:314)
> at io.undertow.servlet.spec.ServletInputStreamImpl$1$1.run(ServletInputStreamImpl.java:135)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: UT010035: Stream in async mode was not ready for IO operation
> at io.undertow.servlet.spec.ServletContextImpl.invokeOnDataAvailable(ServletContextImpl.java:1011)
> at io.undertow.servlet.spec.ServletInputStreamImpl$ServletInputStreamChannelListener.handleEvent(ServletInputStreamImpl.java:295)
> ... 3 more
> Caused by: java.lang.IllegalStateException: UT010035: Stream in async mode was not ready for IO operation
> at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:164)
> at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:154)
> at org.resteasy.simple.deployment.er2.ResourceInfoInjectionResource$1.onDataAvailable(ResourceInfoInjectionResource.java:42)
> at io.undertow.servlet.spec.ServletContextImpl$3.call(ServletContextImpl.java:188)
> at io.undertow.servlet.spec.ServletContextImpl$3.call(ServletContextImpl.java:185)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.spec.ServletContextImpl.invokeOnDataAvailable(ServletContextImpl.java:1009)
> ... 4 more
> {code}
> The exception mentions that HTTP 500, should be returned.
> [Comment|https://issues.jboss.org/browse/JBEAP-12223?focusedCommentId=1363...] from [~rpelisse] previous JIRA:
> {quote}Thanks for the step to reproduce, I've also managed to reproduce the behavior. Debugging through the problem, i've established that the code inserted to adress the isssue is still being used, the exception that lead to a 500 error to be returned is no longer being leading to 500 (but a 200).
> If I'm not mistaken, CD13 used Undertow 2.0.9 while CD14 is now using 2.0.13. I'll keep looking tomorrow to which of the few commits introduced in between those versions can have caused the issue.
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11095) Wildfly 14.0.0 regression: EL returns empty string on constant
by Adam Krajcik (Jira)
[ https://issues.jboss.org/browse/WFLY-11095?page=com.atlassian.jira.plugin... ]
Adam Krajcik commented on WFLY-11095:
-------------------------------------
I tried it according to your example and I get the same behavior as in [WFLY-11086|https://issues.jboss.org/browse/WFLY-11086].
I used the nightly buld of Wildfly with the [WFLY-11065|https://issues.jboss.org/browse/WFLY-11065] resolved.
My steps:
# Create class MyConstants with constant HELLO
{code}
public class MyConstants {
public static final String HELLO = "hello world.";
}
{code}
# Create index.jsp:
{code}
<%@ page import="org.jboss.qa.management.web.resources.MyConstants" %>
<html><body>--- ${MyConstants.HELLO} ---</body></html>
{code}
# Create jsp-example.war
# Make requests
{code}
curl 127.0.0.1:8080/jsp-example/
{code}
On the first request, I get back correct answer:
{code}
<html><body>--- hello world. ---</body></html>
{code}
And on the second and so forth, I get incorrect answer:
{code}
<html><body>--- ---</body></html>
{code}
Thus this still seems as a duplicate to me. Please, let us know whether your use case differs somehow or whether we missed something. Thanks.
> Wildfly 14.0.0 regression: EL returns empty string on constant
> --------------------------------------------------------------
>
> Key: WFLY-11095
> URL: https://issues.jboss.org/browse/WFLY-11095
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.0.Final
> Environment: Linux
> Reporter: Arthur Borsboom
> Assignee: Stuart Douglas
> Priority: Major
>
> This does work in Wildfly 13, but not in Wildfly 14:
> <%@ page import="com.example.YourConstants" %>
> ${YourConstants.FOO}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-1409) Infinite loop when using maps
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-1409?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1409.
---------------------------------
Resolution: Explained
The memberof operator only works with collections (and arrays) and a map is not a collection. This means that to prevent the infinite loop is enough to apply that operator on the keys of the map and then replace "FLG1 not memberof matchMap" with "FLG1 not memberof matchMap.keySet"
> Infinite loop when using maps
> -----------------------------
>
> Key: DROOLS-1409
> URL: https://issues.jboss.org/browse/DROOLS-1409
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final, 6.5.0.Final
> Environment: Windows/Linux /MacOs
> Reporter: mourad ouachani
> Assignee: Mario Fusco
> Priority: Major
> Attachments: engineMapBug.zip
>
>
> Infinite loop when using maps instead collections.
> The problem appears before the 10th iteration, however if you run it 10 times it could end properly without infinite loop.
>
> We thought it could be linked to the concurrent access to HashMap and we tried with concurrent HashMap but still got the same problem.
> It could be probably linked to the fact that we use maps not only to store the result of some rules evaluation but also as a functional way to prevent rule to be fired again (see rule "FLG1" and the condition "FLG1 not memberof matchMap"
> Thanks.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11102) Wildfly leaks ActiveMQ connections
by Jiri Ondrusek (Jira)
Jiri Ondrusek created WFLY-11102:
------------------------------------
Summary: Wildfly leaks ActiveMQ connections
Key: WFLY-11102
URL: https://issues.jboss.org/browse/WFLY-11102
Project: WildFly
Issue Type: Bug
Affects Versions: 13.0.0.Final
Environment: openjdk 8 / openjdk 9, Linux
Reporter: Jiri Ondrusek
Assignee: Jeff Mesnil
After upgrading our application from wildfly 12 to 13, the app started to crash after a while (hours, days, depending on circumstances). It crashes on
IJ000453: Unable to get managed connection for java:/JmsXA
and other errors (it simply cannot perform all the jobs it contains). I found that when shutting down the server which has been running for a while, I can see a bunch of these messages in the log:
WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (ServerService Thread Pool -- 117) [:::] IJ000615: Destroying active connection in pool: ActiveMQConnectionDefinition (org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection@2f37f69)
Bascially, the longer the server was running, more of these messages are shown. I cannot find a way how to reproduce the issue. When the server runs for short time but with some load, no connection is leaked (or just one, rarely). On the other side, it leaks connections even without any particularly high load (just a few requests and @Schedule jobs) when running for longer time.
It may also be a bug in our application, which just happen to have more serious impact with the new wildfly version.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months