August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4386) Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8

by Rahul Ramachar (Jira)

Rahul Ramachar created DROOLS-4386: -------------------------------------- Summary: Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8 Key: DROOLS-4386 URL: https://issues.jboss.org/browse/DROOLS-4386 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 6.5.0.Final Environment: Windows, Java 1.8 and drools 6.5.0.Final Reporter: Rahul Ramachar Assignee: Mario Fusco In JDK 1.7 we were using Drools 5.3.0.Final version and we are migrating to jdk 1.8 so drools 5.3.0.Final was not supported in which we were using Package Builder. We migrated JDK 1.8 with drools 6.5.0.Final which uses Kie API to implement rules Below is the decision table I am using: Customer Rule: Condition Condition Action --------------------------------------------------- Rule NO. Type Years Discount --------------------------------------------------- 1 "Individual" 5 15 2 "Individual" 3 10 3 "Individual" 20 if I insert customer object as "Type" = Individual and "Years" = 5 after fireAllRules It fires two rules i.e Rule no. 1 and 3 and gives the 3rd Rule number as result instead of Rule number 1, inturn gives Discount as 20 instead of 15 which is wrong result. if I insert customer object as "Type" = Individual and "Years" = 3 after fireAllRules It fires two rules i.e Rule no. 2 and 3 and gives the 3rd rule number as result instead of Rule number 2, inturn gives Discount as 20 instead of 10 which is wrong result. Exact rule match is not happening and providing wrong results. Could you please give the solution for this it is breaking so many rules in the application. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4385) Change FactHandle ID from a Integer into a Long

by Sudhish Nair (Jira)

[ https://issues.jboss.org/browse/DROOLS-4385?page=com.atlassian.jira.plugi... ] Sudhish Nair deleted DROOLS-4385: --------------------------------- > Change FactHandle ID from a Integer into a Long > ----------------------------------------------- > > Key: DROOLS-4385 > URL: https://issues.jboss.org/browse/DROOLS-4385 > Project: Drools > Issue Type: Enhancement > Reporter: Sudhish Nair > Assignee: Mario Fusco > Priority: Major > > Change FactHandle ID from a Integer into a Long keeping backward compatibility of serialized KieSession. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4385) Change FactHandle ID from a Integer into a Long

by Sudhish Nair (Jira)

Sudhish Nair created DROOLS-4385: ------------------------------------ Summary: Change FactHandle ID from a Integer into a Long Key: DROOLS-4385 URL: https://issues.jboss.org/browse/DROOLS-4385 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Sudhish Nair Assignee: Mario Fusco Change FactHandle ID from a Integer into a Long keeping backward compatibility of serialized KieSession. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2602) Download link for particular KIE Execution Server war instead of zip with wars for all containers

by Marek Novotny (Jira)

[ https://issues.jboss.org/browse/DROOLS-2602?page=com.atlassian.jira.plugi... ] Marek Novotny commented on DROOLS-2602: --------------------------------------- [~azarny] Just curious why can't you use files from Maven repository ? like https://repo1.maven.org/maven2/org/kie/server/kie-server/7.24.0.Final/kie... ? For CI usage it is even more convenient than downloading from Downloads on website. > Download link for particular KIE Execution Server war instead of zip with wars for all containers > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-2602 > URL: https://issues.jboss.org/browse/DROOLS-2602 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.7.0.Final > Reporter: Igor Azarny > Assignee: Michael Biarnes Kiefer > Priority: Optional > Labels: distribution > > Could you please provide the download link for particular KIE Execution Server war instead of zip with wars for all containers? > Reason - need to create buildpack with kie server for pivotal cloud foundry on CI env. So I need just kie-server-7.7.0.Final-webc.war instead of kie-server-distribution-7.7.0.Final.zip > Thanks, Igor -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2362) Providing logical member name in JDBC_PING

by S Pokutniy (Jira)

[ https://issues.jboss.org/browse/JGRP-2362?page=com.atlassian.jira.plugin.... ] S Pokutniy commented on JGRP-2362: ---------------------------------- Sure, apologies for unclear description. What happens is this: 1) I can hardly use CREATE Table in parameter initialize_sql in JDBC_PING as it is done in an DML in my case. 2) My servers do crash frequently and can also be killed. If I do not do any clearing of old datasets the new start of the server lasts 3 (GSM.getJoinClusterTimeout) * 10(GSM.MaxJoinAttempts) * number of old entries = i.e. at least 30 seconds * number of old entries for the same server with its old UUID. Parameter remove_all_data_on_view_change does not seem to clear the data only when coordinator changes. 3) Therefore I would like to delete old entries in JDBC_PING's parameter initialize_sql by using delete from JGROUPSPING where coordinator = x or logical_name = x As own_addr is a UUID and is always different it can hardly be used here and the logical address or the channel name would be a gain here but it is not there. In the source code I see that adding it would not be that diffecult as the data is already available in the object PingData. If it is unclear I would gladly write more details. > Providing logical member name in JDBC_PING > ------------------------------------------ > > Key: JGRP-2362 > URL: https://issues.jboss.org/browse/JGRP-2362 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20 > Reporter: S Pokutniy > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.2 > > > When using JDBC_PING and logical names instead of UUIDs and one of the cluster member crashes or get killed and this member is not coordinator then its database set still remains in the database as long as coordinator changes (independently from remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is then restarted the old dataset makes connect() much slower (+30 seconds), as the members seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be the solution but it does not work as long as coordinator does not change, so practically the same as remove_old_coords_on_view_change. > The only solution seems to be to provide an appropriate delete statement in parameter initialize_sql, which would delete old entry, for example like this: delete from JGROUPSPING where ping_data like '%logical name%'. However, this is neither really quick nor the ideal solution, as ping_data's datatype is bytea or bit varying. > It would be great to have also logical name in JGROUPSPING, which is instead per default in insert(). This is also easy to implement as there is access to this information in PingData. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12322) Avoid redispatching to a worker the ejb call if it is not async (at AssociationImpl)

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-12322?page=com.atlassian.jira.plugin... ] Flavia Rainone updated WFLY-12322: ---------------------------------- Summary: Avoid redispatching to a worker the ejb call if it is not async (at AssociationImpl) (was: Avoid redispatching to a worker the ejb call if it is async (at AssociationImpl)) > Avoid redispatching to a worker the ejb call if it is not async (at AssociationImpl) > ------------------------------------------------------------------------------------ > > Key: WFLY-12322 > URL: https://issues.jboss.org/browse/WFLY-12322 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Reporter: Flavia Rainone > Assignee: Stuart Douglas > Priority: Major > Fix For: 18.0.0.Beta1 > > > Prevent the extra cost of dispatching the message at AssociationImpl.execute if the message is synchronous, by just executing it right away -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-903) Fix/refactor checker script

by Filip Brychta (Jira)

Filip Brychta created SWSQE-903: ----------------------------------- Summary: Fix/refactor checker script Key: SWSQE-903 URL: https://issues.jboss.org/browse/SWSQE-903 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta We converted the kiali/istio/bookinfo checker script to jenkins DSL - https://issues.jboss.org/browse/SWSQE-749 The script is not working properly and needs to be fixed. https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/checker-jobs/j... -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 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 edited comment on JGRP-2364 at 8/1/19 3:51 AM: -------------------------------------------------------- The problem is that unlock() doesn't wait for the RELEASE_LOCK_OK response. If we do a lock-unlock-lock sequence, the second lock() request will not send a GRANT_LOCK request if the lock is still locked. This can happen if the second lock() is sent _before_ the RELEASE_LOCK_OK response has been received. Fix: block {{unlock()}} until the RELEASE_LOCK_OK response has been received (same as for {{lock()}}) was (Author: belaban): The problem is that unlock() doesn't wait for the RELEASE_LOCK_OK response. If we do a lock-unlock-lock sequence, the second lock() request will not send a GRANT_LOCK request if the lock is still locked. This can happen if the second lock() is sent _before_ the RELEASE_LOCK_OK response has been received. Fix: block`unlock()` until the RELEASE_LOCK_OK response has been received (same as for `lock()`) > 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)

4 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: -------------------------------- The problem is that unlock() doesn't wait for the RELEASE_LOCK_OK response. If we do a lock-unlock-lock sequence, the second lock() request will not send a GRANT_LOCK request if the lock is still locked. This can happen if the second lock() is sent _before_ the RELEASE_LOCK_OK response has been received. Fix: block`unlock()` until the RELEASE_LOCK_OK response has been received (same as for `lock()`) > 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)

4 years, 9 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: -------------------------------- OK, this seems to be a duplicate of JGRP-2364. I'll tackle JGRP-2364 first, and then see if this fixes this issue, too. > 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)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019