August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2299 at 8/21/19 9:24 AM: --------------------------------------------------------- [~dwhitejazz] Could be because the request handler (req_handler) runner is not stopped on stop(), just on a view change. I added method stop() in master, can you check out master and see if this works for you? The commit is 230766825a7db3d6806539fbe88210bdaa8509fa. If not, can you describe how to reproduce this? was (Author: belaban): Could be because the request handler (req_handler) runner is not stopped on stop(), just on a view change. I added method stop() in master, can you check out master and see if this works for you? The commit is 230766825a7db3d6806539fbe88210bdaa8509fa. If not, can you describe how to reproduce this? > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: JGroupsExample.java, image.png, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2299: -------------------------------- Could be because the request handler (req_handler) runner is not stopped on stop(), just on a view change. I added method stop() in master, can you check out master and see if this works for you? The commit is 230766825a7db3d6806539fbe88210bdaa8509fa. If not, can you describe how to reproduce this? > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: JGroupsExample.java, image.png, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4448) [Guided Rule] Local Date constraint is lost

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4448?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4448: -------------------------------- Description: User is unable to create guided rule with constraint over {{LocalDate}} field. h2. Acceptance criteria Save and reopen all these column types - Free form DRL, constraint - Simple condition column, literal value constraint - BRL condition column, literal value constrain - BRL condition column, template key constraint - Simple action column - BRL action column, literal value - BRL action column, template key was:User is unable to create guided rule with constraint over {{LocalDate}} field. > [Guided Rule] Local Date constraint is lost > ------------------------------------------- > > Key: DROOLS-4448 > URL: https://issues.jboss.org/browse/DROOLS-4448 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Jozef Marko > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > User is unable to create guided rule with constraint over {{LocalDate}} field. > h2. Acceptance criteria > Save and reopen all these column types > - Free form DRL, constraint > - Simple condition column, literal value constraint > - BRL condition column, literal value constrain > - BRL condition column, template key constraint > - Simple action column > - BRL action column, literal value > - BRL action column, template key -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4452) [GDST] Wrong FQCN is selected if the end matches.

by Toni Rikkola (Jira)

Toni Rikkola created DROOLS-4452: ------------------------------------ Summary: [GDST] Wrong FQCN is selected if the end matches. Key: DROOLS-4452 URL: https://issues.jboss.org/browse/DROOLS-4452 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor Reporter: Toni Rikkola Assignee: Toni Rikkola If the column uses class Person. The FQCN resolver that fills the DMO uses the first import that end with the class name. For example if the list contains: * org.test.AnotherPerson * org.test.Person Then first item is selected instead of the second. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4448) [Guided Rule] Local Date constraint is lost

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4448?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4448: -------------------------------- Description: User is unable to create guided rule with constraint over {{LocalDate}} field. (was: User is unable to create guided rule with constraint over {LocalDate} field.) > [Guided Rule] Local Date constraint is lost > ------------------------------------------- > > Key: DROOLS-4448 > URL: https://issues.jboss.org/browse/DROOLS-4448 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Jozef Marko > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > User is unable to create guided rule with constraint over {{LocalDate}} field. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12404) High Fail rate with MOD_JK and JDG remote-cache-container

by Tommasso Borgato (Jira)

[ https://issues.jboss.org/browse/WFLY-12404?page=com.atlassian.jira.plugin... ] Tommasso Borgato updated WFLY-12404: ------------------------------------ Description: Scenario: 2 nodes WildFly cluster where session data is offloaded to a remote 2 nodes JDG cluster (jboss-datagrid-7.3.0); When using MOD_JK as load balancer we observe a higher fail rate (~9%) than when using MOD_CLUSTER or HAPROXY (~0.9%); fail rate is intended as inconsistencies in the data stored in cache and subsequently retrieved on another node of the cluster: * [MOD_JK|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x...] * [MOD_CLUSTER|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ea...] * [HAPROXY|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7....] was: Scenario: 2 nodes EAP cluster where session data is offloaded to a remote 2 nodes JDG cluster (jboss-datagrid-7.3.0); When using MOD_JK as load balancer we observe a higher fail rate (~9%) than when using MOD_CLUSTER or HAPROXY (~0.9%); fail rate is intended as inconsistencies in the data stored in cache and subsequently retrieved on another node of the cluster: * [MOD_JK|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x...] * [MOD_CLUSTER|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ea...] * [HAPROXY|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7....] > High Fail rate with MOD_JK and JDG remote-cache-container > --------------------------------------------------------- > > Key: WFLY-12404 > URL: https://issues.jboss.org/browse/WFLY-12404 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.0.Beta1 > Reporter: Tommasso Borgato > Assignee: Paul Ferraro > Priority: Major > > Scenario: 2 nodes WildFly cluster where session data is offloaded to a remote 2 nodes JDG cluster (jboss-datagrid-7.3.0); > When using MOD_JK as load balancer we observe a higher fail rate (~9%) than when using MOD_CLUSTER or HAPROXY (~0.9%); fail rate is intended as inconsistencies in the data stored in cache and subsequently retrieved on another node of the cluster: > * [MOD_JK|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x...] > * [MOD_CLUSTER|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ea...] > * [HAPROXY|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7....] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12404) High Fail rate with MOD_JK and JDG remote-cache-container

by Tommasso Borgato (Jira)

Tommasso Borgato created WFLY-12404: --------------------------------------- Summary: High Fail rate with MOD_JK and JDG remote-cache-container Key: WFLY-12404 URL: https://issues.jboss.org/browse/WFLY-12404 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.0.Beta1 Reporter: Tommasso Borgato Assignee: Paul Ferraro Scenario: 2 nodes EAP cluster where session data is offloaded to a remote 2 nodes JDG cluster (jboss-datagrid-7.3.0); When using MOD_JK as load balancer we observe a higher fail rate (~9%) than when using MOD_CLUSTER or HAPROXY (~0.9%); fail rate is intended as inconsistencies in the data stored in cache and subsequently retrieved on another node of the cluster: * [MOD_JK|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x...] * [MOD_CLUSTER|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ea...] * [HAPROXY|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7....] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4451) [DMN Designer] Rename 1.1 package to model in the backend

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4451?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4451: -------------------------------- Affects Version/s: 7.26.0.Final > [DMN Designer] Rename 1.1 package to model in the backend > --------------------------------------------------------- > > Key: DROOLS-4451 > URL: https://issues.jboss.org/browse/DROOLS-4451 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.26.0.Final > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > This JIRA was create to address this comment: https://github.com/kiegroup/kie-wb-common/pull/2828#pullrequestreview-277... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4451) [DMN Designer] Rename 1.1 package to model in the backend

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4451: --------------------------------------- Summary: [DMN Designer] Rename 1.1 package to model in the backend Key: DROOLS-4451 URL: https://issues.jboss.org/browse/DROOLS-4451 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes This JIRA was create to address this comment: https://github.com/kiegroup/kie-wb-common/pull/2828#pullrequestreview-277... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-1004) Allow the ** role to be disabled

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/SECURITY-1004?page=com.atlassian.jira.plu... ] Ilia Vassilev closed SECURITY-1004. ----------------------------------- Release Notes Text: We don't fix PicketBox issues upstream. Resolution: Won't Fix > Allow the ** role to be disabled > -------------------------------- > > Key: SECURITY-1004 > URL: https://issues.jboss.org/browse/SECURITY-1004 > Project: PicketBox > Issue Type: Enhancement > Components: JBossSX, Security-SPI > Reporter: Brad Maxwell > Assignee: Ilia Vassilev > Priority: Major > > Allow the ** role to be disabled as it cause a performance degradation > -- 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