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 commented on JGRP-2299: -------------------------------- JGRP-2364 fixes this issue, so I'm resolving it. > 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, 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4395) [DMN Designer] Validation fails for included models

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4395: ----------------------------------- Summary: [DMN Designer] Validation fails for included models Key: DROOLS-4395 URL: https://issues.jboss.org/browse/DROOLS-4395 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.25.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Attachments: Screenshot from 2019-08-02 14-01-32.png The attached screenshot shows an error coming from a dmn file that has a imported another dmn model. All dmn models with imported other models (dmn or pmml) throws an error during validation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4253) Fix SonarCloud report problems in kogito-codegen

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4253?page=com.atlassian.jira.plugi... ] Tibor Zimanyi closed DROOLS-4253. --------------------------------- Resolution: Won't Fix > Fix SonarCloud report problems in kogito-codegen > ------------------------------------------------ > > Key: DROOLS-4253 > URL: https://issues.jboss.org/browse/DROOLS-4253 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Tibor Zimanyi > Assignee: Tibor Zimanyi > Priority: Major > Fix For: 8.0.0.Final > > > When SonarCloud analysis is run on kogito-codegen, it reports 122 problems. It could be common bugs, coding and performance recommendations, etc. These problems should be checked and fixes done where appropriate. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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: -------------------------------- Unit tests added to LockServiceTest: testLockMultipleTimes() and testTryLockMultipleTimes() > 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, 9 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: -------------------------------- OTOH, your proposed fix is good enough and simple! I applied it... runn the test suite now and seeing if this will fix JGRP-2299, too... > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-915) Add nightly trigger for qe tests code coverage

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-915?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-915. --------------------------------- Resolution: Done Added https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/triggers/job/u... > Add nightly trigger for qe tests code coverage > ---------------------------------------------- > > Key: SWSQE-915 > URL: https://issues.jboss.org/browse/SWSQE-915 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > We need the upstream pipeline with a code coverage enabled to be triggered nightly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-915) Add nightly trigger for qe tests code coverage

by Filip Brychta (Jira)

Filip Brychta created SWSQE-915: ----------------------------------- Summary: Add nightly trigger for qe tests code coverage Key: SWSQE-915 URL: https://issues.jboss.org/browse/SWSQE-915 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Assignee: Filip Brychta We need the upstream pipeline with a code coverage enabled to be triggered nightly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-774) Code coverage for kiali - stage 2

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-774?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-774: -------------------------------- Sprint: Kiali Sprint #26 > Code coverage for kiali - stage 2 > --------------------------------- > > Key: SWSQE-774 > URL: https://issues.jboss.org/browse/SWSQE-774 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > In https://issues.jboss.org/browse/SWSQE-699 we enabled code coverage and reporting for system tests. This tasks is to improve it and extend it e.g. to report diff in code coverage in PRs, combine unit with system tests,... > Links: > * https://docs.coveralls.io/go > * https://github.com/codeclimate/test-reporter/issues/292 > * https://blog.antoine-augusti.fr/2015/11/continuous-integration-and-code-c... > * https://github.com/AntoineAugusti/colors > * https://codecov.io/ > * https://jbub.eu/2017/12/02/go-test-coverage/ > * https://github.com/zelenko/go > * https://github.com/jenkinsci/github-pr-coverage-status-plugin -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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: -------------------------------- I should have read your last comment more thoroughly, what I have in mind is exactly the code you wrote! However, I don't think I want to introduce that 10s timeout, but wait forever. I don't think waiting forever is problematic, because the unlock request is resent to a new coordinator (when the old one dies) and we'd introduce an interrupt when the app terminates, so the wait() terminates... > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4067) Add before/afterNodeEvaluated to enable monitoring of engine performance

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4067?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4067: -------------------------------- Sprint: 2019 Week 23-25, 2019 Week 32-34 (was: 2019 Week 23-25, 2019 Week 29-31) > Add before/afterNodeEvaluated to enable monitoring of engine performance > ------------------------------------------------------------------------ > > Key: DROOLS-4067 > URL: https://issues.jboss.org/browse/DROOLS-4067 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 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