August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4392) Deploy pods using a maven plugin

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4392?page=com.atlassian.jira.plugi... ] Massimiliano Dessi updated DROOLS-4392: --------------------------------------- Sprint: 2019 Week 29-31 > Deploy pods using a maven plugin > -------------------------------- > > Key: DROOLS-4392 > URL: https://issues.jboss.org/browse/DROOLS-4392 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4400) Can not open a Scenario Simulation model version 1.5

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4400?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4400: -------------------------------- Summary: Can not open a Scenario Simulation model version 1.5 (was: Can not open a scenario version 1.5) > Can not open a Scenario Simulation model version 1.5 > ---------------------------------------------------- > > Key: DROOLS-4400 > URL: https://issues.jboss.org/browse/DROOLS-4400 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.25.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Attachments: PlaneBoarding3629284258846927242.zip, Screenshot from 2019-08-05 09-39-26.png > > > The latest version (1.6) of Scenario Simulation model is not compatible with previous Scenario Simulation model (1.5). If user tries to open Scenario Simulation created on older product version, an error is thrown. For more detail see the attache Plane Boarding project. There are *.scesim* files with Scenario Simulation model version 1.5, however they can not be opened in business central that has the latest Scenario Simulation model version 1.6. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4400) Can not open a scenario version 1.5

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4400: ----------------------------------- Summary: Can not open a scenario version 1.5 Key: DROOLS-4400 URL: https://issues.jboss.org/browse/DROOLS-4400 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.25.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: PlaneBoarding3629284258846927242.zip, Screenshot from 2019-08-05 09-39-26.png The latest version (1.6) of Scenario Simulation model is not compatible with previous Scenario Simulation model (1.5). If user tries to open Scenario Simulation created on older product version, an error is thrown. For more detail see the attache Plane Boarding project. There are *.scesim* files with Scenario Simulation model version 1.5, however they can not be opened in business central that has the latest Scenario Simulation model version 1.6. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12349) EAT : Adding the basic PR scripts of TC ...

by Panagiotis Sotiropoulos (Jira)

Panagiotis Sotiropoulos created WFLY-12349: ---------------------------------------------- Summary: EAT : Adding the basic PR scripts of TC ... Key: WFLY-12349 URL: https://issues.jboss.org/browse/WFLY-12349 Project: WildFly Issue Type: Task Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos Adding the basic EAT PR scripts of TC ... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4393) expire facts before fire rules

by Alberto Fanjul Alonso (Jira)

[ https://issues.jboss.org/browse/DROOLS-4393?page=com.atlassian.jira.plugi... ] Alberto Fanjul Alonso updated DROOLS-4393: ------------------------------------------ Security: (was: Red Hat Internal) > expire facts before fire rules > ------------------------------ > > Key: DROOLS-4393 > URL: https://issues.jboss.org/browse/DROOLS-4393 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.24.0.Final > Reporter: Alberto Fanjul Alonso > Assignee: Mario Fusco > Priority: Major > Attachments: reproducer-02425402.zip > > > Is there any option to expire the facts before fireAllRules()? > A reproducer for drools 6.5.0.Final-redhat-25 (tested too on 7.23.0.Final-redhat-00002 and 7.24.0.Final) shows that facts are not expired until we run fireAllRules(). > Trying reproducer: > Show facts are expired after fireAllRules(): > ``` > unzip -d reproducer reproducer-02425402.zip > cd reproducer > git checkout master > ./run.sh > ``` > Show facts are not expired before fireAllRules(): > ``` > git checkout original > ./run.sh > ``` -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2364: -------------------------------- Why would RELEASE_LOCK_OK never be sent back? The lock holder sends RELEASE_LOCK to the new coordinator, and UNICAST3 takes care of resending it until received. If there's a scenario in which this fails, why don't you add a unit test to LockServiceTest and I'll fix it. > simply lock and unlock JGroups lock repeatedly will create chaos > ---------------------------------------------------------------- > > Key: JGRP-2364 > URL: https://issues.jboss.org/browse/JGRP-2364 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.1 > Environment: JDK: 1.8 > JGroups: 4.1.1 > Lock: CENTRAL_LOCK > Reporter: Yong Deng > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: LockSimpleTest.java > > > I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?* > * Current log: > {code:java} > 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000] > 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A] > 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31] > 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A] > 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A] > 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > {code} > * The expected log: > {code:java} > 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000) > 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000) > 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2364 at 8/5/19 3:09 AM: -------------------------------------------------------- Resolved. I changed one thing in your code though: you cannot set {{acquired}} and {{denied}} to false when there's no RELEASE_LOCK_OK: this would allow someone else to acquire the lock, and that should not be possible! Scenario: * A,B,C, C holds lock X * A crashes, but the new view \{B,C\} is not yet installed (e.g. because FD_ALL has a high timeout, and FD_SOCK is missing) * C's unlock() request times out waiting for RELEASE_LOCK_OK * If {{acquired}} and {{denied}} were set to false, a new locker would be able to acquire the lock * This way, when view \{B,C\} is received by C, the RELEASE_LOCK request is resent to B and on reception of RELEASE_LOCK_OK, the lock is released, so someone else can acquire it. was (Author: belaban): Resolved. I changed one thing in your code though: you cannot set {{acquired}} and {{denied}} to false when there's no RELEASE_LOCK_OK: this would allow someone else to acquire the lock, and that should not be possible! Scenario: * A,B,C, C holds lock X * A crashes, but the new view \{B,C\} is not yet installed (e.g. because FD_ALL has a high timeout, and FD_SOCK is missing) * C's unlock() request times out waiting for RELEASE_LOCK_OK * If {{acquired}} and {{denied}} were set to false, a new locker would be able to acquire the lock * This way, when view \{B,C\} is received by C, the RELEASE_LOCK request is resent to B and one reception of RELEASE_LOCK_OK, the lock is released, so someone else can acquire it. > simply lock and unlock JGroups lock repeatedly will create chaos > ---------------------------------------------------------------- > > Key: JGRP-2364 > URL: https://issues.jboss.org/browse/JGRP-2364 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.1 > Environment: JDK: 1.8 > JGroups: 4.1.1 > Lock: CENTRAL_LOCK > Reporter: Yong Deng > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: LockSimpleTest.java > > > I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?* > * Current log: > {code:java} > 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000] > 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A] > 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31] > 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A] > 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A] > 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31] > 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31] > {code} > * The expected log: > {code:java} > 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000) > 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000) > 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ] > 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ] > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4257) DMN UX - overlay information about an entire simulation execution

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-4257?page=com.atlassian.jira.plugi... ] Klara Kufova commented on DROOLS-4257: -------------------------------------- [~uxdlc], see the description above. This has both DMN and Test Scenario impact. > DMN UX - overlay information about an entire simulation execution > ----------------------------------------------------------------- > > Key: DROOLS-4257 > URL: https://issues.jboss.org/browse/DROOLS-4257 > Project: Drools > Issue Type: Story > Components: DMN Editor > Affects Versions: 7.24.0.Final > Reporter: Daniele Zonca > Assignee: Margot Menestrot > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam, drools-tools > > Related to https://issues.jboss.org/browse/DROOLS-3731 > This task will cover this use case: > - user creates a DMN model > - user creates a Test Scenario with some scenarios > - user executes the Test Scenario > - user open Coverage Report > - user wants to analyze coverage information of {color:red}the *whole* simulation{color} > - user clicks on "a link" near global coverage information > - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4255) Add KIE server support for deploying custom Prometheus metrics

by Michael Biarnes Kiefer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4255?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer updated DROOLS-4255: ------------------------------------------- Fix Version/s: 7.26.0.Final (was: 7.25.0.Final) > Add KIE server support for deploying custom Prometheus metrics > -------------------------------------------------------------- > > Key: DROOLS-4255 > URL: https://issues.jboss.org/browse/DROOLS-4255 > Project: Drools > Issue Type: Enhancement > Components: kie server > Affects Versions: 7.24.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Major > Labels: CustomerFocus > Fix For: 7.26.0.Final > > > The first implementation of Prometheus support in Kie provided default Prometheus metrics. We should enable our users to deploy their custom Prometheus metrics in addition to default Prometheus metrics already published. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3907) [DMN Designer] Add visual indicators for imported Nodes

by Michael Biarnes Kiefer (Jira)

[ https://issues.jboss.org/browse/DROOLS-3907?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer updated DROOLS-3907: ------------------------------------------- Fix Version/s: 7.26.0.Final (was: 7.25.0.Final) > [DMN Designer] Add visual indicators for imported Nodes > ------------------------------------------------------- > > Key: DROOLS-3907 > URL: https://issues.jboss.org/browse/DROOLS-3907 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Michael Anstis > Priority: Major > Labels: UX, UXTeam, drools-tools > Fix For: 7.26.0.Final > > Attachments: Screen Shot 2019-04-17 at 11.55.39 AM.png, read-only-gridC2.png, read-only-gridC2.png > > > Imported models are read-only. We need to show some form of visual indicator for both Nodes (Graph View) and Boxed Expressions (Grid View). Please see the attachments for proposals for the Grid View. > Design Resolution: > * Option C: https://issues.jboss.org/secure/attachment/12449764/read-only-gridC2.png > * Keeping the hover highlight per row cell as is, because when those elements are clicked the Property panel is updated/reflects. > * Use lock icon for canvas nodes: In the components list and in the graph nodes, as illustrated in: https://issues.jboss.org/secure/attachment/12449758/Screen%20Shot%202019-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019