March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5138) Collection editor for List of Objects

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-5138?page=com.atlassian.jira.plug... ] Daniele Zonca reassigned DROOLS-5138: ------------------------------------- Assignee: Yeser Amer (was: Daniele Zonca) > Collection editor for List of Objects > ------------------------------------- > > Key: DROOLS-5138 > URL: https://issues.redhat.com/browse/DROOLS-5138 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.35.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-03-09 16-06-05.png, bpms_dates.zip > > > There is issue in Test Scenarios when user invokes the collection editor for {{java.util.List<java.lang.Object>}} field. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5138) Collection editor for List of Objects

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5138?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5138: -------------------------------- Tester: Anna Dupliak > Collection editor for List of Objects > ------------------------------------- > > Key: DROOLS-5138 > URL: https://issues.redhat.com/browse/DROOLS-5138 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.35.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-03-09 16-06-05.png, bpms_dates.zip > > > There is issue in Test Scenarios when user invokes the collection editor for {{java.util.List<java.lang.Object>}} field. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5138) Collection editor for List of Objects

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5138: ----------------------------------- Summary: Collection editor for List of Objects Key: DROOLS-5138 URL: https://issues.redhat.com/browse/DROOLS-5138 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.35.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: Screenshot from 2020-03-09 16-06-05.png, bpms_dates.zip There is issue in Test Scenarios when user invokes the collection editor for {{java.util.List<java.lang.Object>}} field. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2406: --------------------------- Fix Version/s: (was: 5.0) > MERGE3 not working with TCP using ForkJoinPool > ---------------------------------------------- > > Key: JGRP-2406 > URL: https://issues.redhat.com/browse/JGRP-2406 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Olivier Peyrusse > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.1 > > Attachments: logs.tgz, project.zip, timeline.txt > > > With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3. > I consistently observed the following, from the point of view of a member M > - M asks for other coordinator views. It contacts A and B > - A and B send their views > - M waits and timeouts for receiving views and abort the merge > - immediately after aborting the merge, M process messages containing the views of A and B. > In [^timeline.txt], you will see the extracts for logs from the various members at play. > After many experiments, the one parameter causing this issue is in the TCP protocol. > {code:xml} > <TCP > ... > thread_pool.use_fork_join_pool="true" /> > {code} > Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine. > Project details: > - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol > - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs. > - [^logs.tgz] contains all logs from the various members involved in the test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2406: -------------------------------- Note https://issues.redhat.com/browse/JGRP-2460 > MERGE3 not working with TCP using ForkJoinPool > ---------------------------------------------- > > Key: JGRP-2406 > URL: https://issues.redhat.com/browse/JGRP-2406 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Olivier Peyrusse > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0, 4.2.1 > > Attachments: logs.tgz, project.zip, timeline.txt > > > With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3. > I consistently observed the following, from the point of view of a member M > - M asks for other coordinator views. It contacts A and B > - A and B send their views > - M waits and timeouts for receiving views and abort the merge > - immediately after aborting the merge, M process messages containing the views of A and B. > In [^timeline.txt], you will see the extracts for logs from the various members at play. > After many experiments, the one parameter causing this issue is in the TCP protocol. > {code:xml} > <TCP > ... > thread_pool.use_fork_join_pool="true" /> > {code} > Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine. > Project details: > - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol > - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs. > - [^logs.tgz] contains all logs from the various members involved in the test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2460) TP: remove ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2460?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2460: -------------------------------- If someone still wants to use the FJP, they can wrap the FJP in an Executor and set it in the transport. > TP: remove ForkJoinPool > ----------------------- > > Key: JGRP-2460 > URL: https://issues.redhat.com/browse/JGRP-2460 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Nobody's using FJP in TP... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2460) TP: remove ForkJoinPool

by Bela Ban (Jira)

Bela Ban created JGRP-2460: ------------------------------ Summary: TP: remove ForkJoinPool Key: JGRP-2460 URL: https://issues.redhat.com/browse/JGRP-2460 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Nobody's using FJP in TP... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2406: -------------------------------- Do you need to use the FJP? I'm thinking of removing this option in 5.0... > MERGE3 not working with TCP using ForkJoinPool > ---------------------------------------------- > > Key: JGRP-2406 > URL: https://issues.redhat.com/browse/JGRP-2406 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Olivier Peyrusse > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0, 4.2.1 > > Attachments: logs.tgz, project.zip, timeline.txt > > > With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3. > I consistently observed the following, from the point of view of a member M > - M asks for other coordinator views. It contacts A and B > - A and B send their views > - M waits and timeouts for receiving views and abort the merge > - immediately after aborting the merge, M process messages containing the views of A and B. > In [^timeline.txt], you will see the extracts for logs from the various members at play. > After many experiments, the one parameter causing this issue is in the TCP protocol. > {code:xml} > <TCP > ... > thread_pool.use_fork_join_pool="true" /> > {code} > Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine. > Project details: > - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol > - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs. > - [^logs.tgz] contains all logs from the various members involved in the test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11933) Error when accessing metrics with RBAC enabled

by Claudio Weiler (Jira)

[ https://issues.redhat.com/browse/WFLY-11933?page=com.atlassian.jira.plugi... ] Claudio Weiler updated WFLY-11933: ---------------------------------- Description: Accordingly to https://docs.wildfly.org/17/Admin_Guide.html#http-endpoint-2 and https://wildscribe.github.io/WildFly/17.0/subsystem/microprofile-metrics-..., access to metrics endpoint is controlled by the security-enabled attribute. When this attribute is set to false, there is an Exception when metrics are accessed. By default, this attribute is set to false on standalone.xml config. Please, refer to steps to reproduce. This error occurs only when RBAC are enabled. When RBAC is enabled for management in Wildfly, metrics throws exception: java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute XAForgetAverageTime on [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS"), ("statistics" => "pool") ]: "WFLYCTL0216: Management resource '[ (\"subsystem\" => \"datasources\"), (\"data-source\" => \"ExampleDS\"), (\"statistics\" => \"pool\") ]' not found". was: When RBAC is enabled for management in Wildfly, metrics throws exception: java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute XAForgetAverageTime on [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS"), ("statistics" => "pool") ]: "WFLYCTL0216: Management resource '[ (\"subsystem\" => \"datasources\"), (\"data-source\" => \"ExampleDS\"), (\"statistics\" => \"pool\") ]' not found". > Error when accessing metrics with RBAC enabled > ---------------------------------------------- > > Key: WFLY-11933 > URL: https://issues.redhat.com/browse/WFLY-11933 > Project: WildFly > Issue Type: Bug > Components: Management, MP Metrics > Affects Versions: 16.0.0.Final, 17.0.0.Final, 17.0.1.Final > Reporter: Claudio Weiler > Assignee: Jeff Mesnil > Priority: Major > > Accordingly to https://docs.wildfly.org/17/Admin_Guide.html#http-endpoint-2 and https://wildscribe.github.io/WildFly/17.0/subsystem/microprofile-metrics-..., access to metrics endpoint is controlled by the security-enabled attribute. > When this attribute is set to false, there is an Exception when metrics are accessed. By default, this attribute is set to false on standalone.xml config. > Please, refer to steps to reproduce. This error occurs only when RBAC are enabled. > When RBAC is enabled for management in Wildfly, metrics throws exception: > java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute XAForgetAverageTime on [ > ("subsystem" => "datasources"), > ("data-source" => "ExampleDS"), > ("statistics" => "pool") > ]: "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"datasources\"), > (\"data-source\" => \"ExampleDS\"), > (\"statistics\" => \"pool\") > ]' not found". -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5119) [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL

by Bhala Hadkar (Jira)

[ https://issues.redhat.com/browse/DROOLS-5119?page=com.atlassian.jira.plug... ] Bhala Hadkar commented on DROOLS-5119: -------------------------------------- In my case usually value disappears once I log off and log in back to Workbench. Could you please login back to workbench and see if it still shows 100. Is there a way I can find which version of Workbench I am using? > [Guided Rule Editor] Workbench BigDecimal value turns into 0.0 in DRL > --------------------------------------------------------------------- > > Key: DROOLS-5119 > URL: https://issues.redhat.com/browse/DROOLS-5119 > Project: Drools > Issue Type: Bug > Components: Examples (Workbench), Guided Rule Editor > Affects Versions: 7.34.0.Final > Reporter: Bhala Hadkar > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: DROOLS-5119-rule.png, Workbench-Guided-Rule.png, drools.png > > > When I set up a Guided rule on Workbench having a comparison condition on one of the domain field of type Big Decimal then the int value entered through literal text disappears and turns into 0.0B. > For e.g. if you look at this Guided Rule screenshot the literal value 100 turned into 0.0. > !Workbench-Guided-Rule.png|thumbnail! > Also in the drools the value becomes 0.0B. > !drools.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 March 2020