April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2502) Declare role event erase exists class

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2502?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-2502: ----------------------------------- Assignee: Toni Rikkola (was: Mario Fusco) > Declare role event erase exists class > ------------------------------------- > > Key: DROOLS-2502 > URL: https://issues.jboss.org/browse/DROOLS-2502 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.5.0.Final, 7.0.0.Final, 7.1.0.Final, 7.2.0.Final, 7.3.0.Final, 7.4.1.Final, 7.5.0.Final, 7.6.0.Final, 7.7.0.Final > Environment: Kie workbench + one kie execution server. Java 8. Statefull session. Stream mode. > Reporter: Alexander Revkov > Assignee: Toni Rikkola > Attachments: RN.TEST.zip > > > Declare @role(event) rewrite exists class in drools workbench and kie execution server. > All methods are losts. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2507) Constraints checking against a null value isn't generated correctly by the executable model

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2507?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2507. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/17154e3d1ccfc20e332f432d3827cf6... > Constraints checking against a null value isn't generated correctly by the executable model > ------------------------------------------------------------------------------------------- > > Key: DROOLS-2507 > URL: https://issues.jboss.org/browse/DROOLS-2507 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2508) Constraints checking against a null value isn't generated correctly by the executable model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2508: ----------------------------------- Summary: Constraints checking against a null value isn't generated correctly by the executable model Key: DROOLS-2508 URL: https://issues.jboss.org/browse/DROOLS-2508 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2507) Constraints checking against a null value isn't generated correctly by the executable model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2507: ----------------------------------- Summary: Constraints checking against a null value isn't generated correctly by the executable model Key: DROOLS-2507 URL: https://issues.jboss.org/browse/DROOLS-2507 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2266?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2266: -------------------------------- You're right; since {{run()}} is called every {{reconnect_interval}} ms, we don't need to loop in {{run()}}. > RouterStubManager.run() endless reconnect loop burning a CPU > ------------------------------------------------------------ > > Key: JGRP-2266 > URL: https://issues.jboss.org/browse/JGRP-2266 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.11 > Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes. > Reporter: Emmeran Seehuber > Assignee: Bela Ban > Fix For: 4.0.12 > > Attachments: cs_stack.xml > > > RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU. > E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down. > No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up? > As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2262: --------------------------- Fix Version/s: 3.6.16 Backporting to 3.6.16; testsuite is in progress... > "Frozen" coordinator causes the whole cluster to hang > ----------------------------------------------------- > > Key: JGRP-2262 > URL: https://issues.jboss.org/browse/JGRP-2262 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7 > Reporter: Pietro Paolini > Assignee: Bela Ban > Fix For: 4.0.12, 3.6.16 > > Attachments: jdbc_test.xml, jgroup.zip > > > This is the result of an investigation I carried out for a problem we have experienced within our > application, the scenario it has been re-created by pausing the JVM using a debugger. > The discovery mechanism is JDBC_PING. > If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely. > This seems to be caused by the "continue" statement at > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... > I have prepared a simple application which can help in replicating the problem. > To replicate the problem : > 1) Make sure the JGROUPSPING is empty > 2) Run the application using an IDE and attaching a debugger to cause the JVM to > be paused at line Main.java:67, wait for it. > 3) Run the application in non debug mode or with gradle using "gradle run" and it will > hang indefinitely > Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-271) Support running on Java 11

by Christian Beikov (JIRA)

[ https://issues.jboss.org/browse/JASSIST-271?page=com.atlassian.jira.plugi... ] Christian Beikov updated JASSIST-271: ------------------------------------- Git Pull Request: https://github.com/jboss-javassist/javassist/pull/198 > Support running on Java 11 > -------------------------- > > Key: JASSIST-271 > URL: https://issues.jboss.org/browse/JASSIST-271 > Project: Javassist > Issue Type: Enhancement > Affects Versions: 3.22.0-GA > Environment: Java 11 > Reporter: Christian Beikov > Assignee: Shigeru Chiba > > The GitHub issue describes the problem when running on Java 11 and also has a hint for a fix: https://github.com/jboss-javassist/javassist/issues/194 > The main problem is that {{Unsafe.defineClass}} was removed in Java 11 and Javassist always tries to define classes through that method for JVMs >= 9 which leads to an error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-271) Support running on Java 11

by Christian Beikov (JIRA)

Christian Beikov created JASSIST-271: ---------------------------------------- Summary: Support running on Java 11 Key: JASSIST-271 URL: https://issues.jboss.org/browse/JASSIST-271 Project: Javassist Issue Type: Enhancement Affects Versions: 3.22.0-GA Environment: Java 11 Reporter: Christian Beikov Assignee: Shigeru Chiba The GitHub issue describes the problem when running on Java 11 and also has a hint for a fix: https://github.com/jboss-javassist/javassist/issues/194 The main problem is that {{Unsafe.defineClass}} was removed in Java 11 and Javassist always tries to define classes through that method for JVMs >= 9 which leads to an error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10310) Incorrect license link for LGPL v2.1 or later

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-10310: --------------------------------------- Summary: Incorrect license link for LGPL v2.1 or later Key: WFLY-10310 URL: https://issues.jboss.org/browse/WFLY-10310 Project: WildFly Issue Type: Bug Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry The links on the licenses.html file point to a .html file for the license, but the actual file is .txt so the link is broken. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2198) Reduce log level for RequestCorrelator "channel is not connected" error during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2198: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1463387|https://bugzilla.redhat.com/show_bug.cgi?id=1463387] from ON_QA to VERIFIED > Reduce log level for RequestCorrelator "channel is not connected" error during shutdown > --------------------------------------------------------------------------------------- > > Key: JGRP-2198 > URL: https://issues.jboss.org/browse/JGRP-2198 > Project: JGroups > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > > This is a followup of JGRP-1958. > While the fix for JGRP-1958 https://github.com/belaban/JGroups/commit/03d7c93145f6a9314c2380f5ad66bdc... > removed the stack trace, the error message is still logged as SEVERE. > [~shay1680], [~jbilek] and [~dereed] all agree that the log level should be reduced to WARN. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018