[JBoss JIRA] (JGRP-2365) Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2365?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2365.
----------------------------
Resolution: Done
> Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
> -----------------------------------------------------------------
>
> Key: JGRP-2365
> URL: https://issues.jboss.org/browse/JGRP-2365
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1
> Reporter: Bernd Laengerich
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: fork-stacks.xml, tcp_fork.xml
>
>
> Updating from 4.0.20 to 4.1.1 I get
> "java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP"
> when creating a JChannel using the same config as before. My config is [^tcp_fork.xml] attached to this issue. The stack trace:
> {noformat}
> java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP
> at org.jgroups.stack.Configurator.createProtocolsAndInitializeAttrs(Configurator.java:110) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:273) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:265) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.init(FORK.java:100) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:480) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.init(JChannel.java:952) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:125) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:107) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at com.acceptis.accept.jgroups.config.JGroupsConfigurator.setConfiguration(JGroupsConfigurator.java:86) [main/:?]
> at com.acceptis.framework.locking.impl.test.JGroupsLockManagerTest.setUp(JGroupsLockManagerTest.java:40) [test/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JGRP-2365) Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2365?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2365:
---------------------------
Fix Version/s: 4.1.2
> Class cast exception when upgrading from 4.0.20 to 4.1.0 or 4.1.1
> -----------------------------------------------------------------
>
> Key: JGRP-2365
> URL: https://issues.jboss.org/browse/JGRP-2365
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1
> Reporter: Bernd Laengerich
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: fork-stacks.xml, tcp_fork.xml
>
>
> Updating from 4.0.20 to 4.1.1 I get
> "java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP"
> when creating a JChannel using the same config as before. My config is [^tcp_fork.xml] attached to this issue. The stack trace:
> {noformat}
> java.lang.ClassCastException: org.jgroups.protocols.CENTRAL_LOCK cannot be cast to org.jgroups.protocols.TP
> at org.jgroups.stack.Configurator.createProtocolsAndInitializeAttrs(Configurator.java:110) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:273) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.createForkStacks(FORK.java:265) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.protocols.FORK.init(FORK.java:100) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:480) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.init(JChannel.java:952) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:125) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:107) ~[jgroups-4.1.1.Final.jar:4.1.1.Final]
> at com.acceptis.accept.jgroups.config.JGroupsConfigurator.setConfiguration(JGroupsConfigurator.java:86) [main/:?]
> at com.acceptis.framework.locking.impl.test.JGroupsLockManagerTest.setUp(JGroupsLockManagerTest.java:40) [test/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4381) BigDecimal and primitive comparison error in executable-model build
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4381?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-4381:
--------------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/2482
> BigDecimal and primitive comparison error in executable-model build
> -------------------------------------------------------------------
>
> Key: DROOLS-4381
> URL: https://issues.jboss.org/browse/DROOLS-4381
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.24.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> When you compare BigDecimal (but the field type is Object) with primitive int,
> {noformat}
> import org.drools.modelcompiler.domain.Result;
> rule "rule1"
> when
> $r : Result( value <= 20 )
> then
> end
> {noformat}
> executable-model build fails.
> {noformat}
> [ERROR] Failures:
> [ERROR] CompilerTest.testBigDecimalIntCoercion:1901->BaseModelTest.getKieSession:99->BaseModelTest.getKieSession:103->BaseModelTest.getKieContainer:107->BaseModelTest.getKieContainer:114->BaseModelTest.createKieBuilder:125->BaseModelTest.createKieBuilder:152 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=24, column=122
> text=no suitable method found for lessOrEqualNumbers(java.lang.Object,int)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Number,java.lang.Number) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Number)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Long,java.lang.Long) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Long)], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java in error:
> {noformat}
> Non executable-model works with the rule.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4381) BigDecimal and primitive comparison error in executable-model build
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-4381:
-----------------------------------------
Summary: BigDecimal and primitive comparison error in executable-model build
Key: DROOLS-4381
URL: https://issues.jboss.org/browse/DROOLS-4381
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.24.0.Final
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
When you compare BigDecimal (but the field type is Object) with primitive int,
{noformat}
import org.drools.modelcompiler.domain.Result;
rule "rule1"
when
$r : Result( value <= 20 )
then
end
{noformat}
executable-model build fails.
{noformat}
[ERROR] Failures:
[ERROR] CompilerTest.testBigDecimalIntCoercion:1901->BaseModelTest.getKieSession:99->BaseModelTest.getKieSession:103->BaseModelTest.getKieContainer:107->BaseModelTest.getKieContainer:114->BaseModelTest.createKieBuilder:125->BaseModelTest.createKieBuilder:152 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=24, column=122
text=no suitable method found for lessOrEqualNumbers(java.lang.Object,int)
method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Number,java.lang.Number) is not applicable
(argument mismatch; java.lang.Object cannot be converted to java.lang.Number)
method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Long,java.lang.Long) is not applicable
(argument mismatch; java.lang.Object cannot be converted to java.lang.Long)], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=0, column=0
text=Java source of src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java in error:
{noformat}
Non executable-model works with the rule.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11328) EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11328?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-11328:
--------------------------------------
I did a quick search in the spec and it says:
{quote}
*3.2.5 System Administrator’s Responsibilities*
The System Administrator (EE.2.110.5) is responsible for monitoring and overseeing the runtime environment.
In the scope of this specification, these duties may include:
* Monitoring for hung tasks.
* Monitoring resource usage (for example, threads and memory).
{quote}
It doesn't indicate how an administrator would do that or the fact that it's required to monitor for a hung thread. Deprecation is the simplest approach IMO.
Another option would be to extend or expose the {{ManagedThread.isTaskHun()}} in a custom {{Future}} and leave the checking up to the user.
> EE Concurency Utilities "hung-task-threshold" / "long-running-tasks" do not work and are not implemented as explained
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11328
> URL: https://issues.jboss.org/browse/WFLY-11328
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
>
> ee subsystem parameters "hung-task-threshold" and "long-running-tasks" for managed-executor-service / managed-scheduled-executor-service do not work and are not implemented as described in [EAP 7 Development Guide|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterpr...]:
> - hung-task-threshold: Defines the time, in milliseconds, after which tasks are considered hung by the managed executor service and forcefully aborted. If the value is 0 (which is the default), tasks are never considered hung.
> - long-running-tasks: Suggests optimizing the execution of long running tasks, and defaults to false.
> I tested with [EAP 7 QuickStarts managed-executor-service example|https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.0...] but these paremeters doe not take any effect:
> - tasks exceeding hung-task-threshold are never forcefully aborted. And there's no way to detect hung tasks exceeding hung-task-threshold.
> - setting long-running-tasks to true does not change the behavior.
> As far as I checked the source code, I noticed the following:
> - EAP 7.x uses the EE Concurency Utilities RI [org.glassfish.enterprise.concurrent|https://github.com/javaee/cu-ri] internally and just passes the paramters to the RI.
> - In the EE Concurency Utilities RI, these parameters are used in the methods [ManagedThreadFactoryImpl#isTaskHung(long now)|https://github.com/javaee/cu-ri/blob/master/src/main/java/org/glassf...], [AbstractManagedExecutorService#getHungThreads()|https://github.com/javaee...] and [AbstractManagedExecutorService#isLongRunningTasks()|https://github.com/ja...] (AbstractManagedExecutorService is the parent class of ManagedExecutorServiceImpl / ManagedScheduledExecutorServiceImpl).
> - However, these methods are never invoked from EAP 7.x. So, these parameters do not take any effect in EAP 7.x.
> - In addition, even if these methods are used, it looks the implementation is totally different from the description in the documentation. The parameter "long-running-tasks" is just used as a flag to skip from checking hung thread detection. And the parameter "hung-task-threshold" never forcefully abort the hung thread exceeding the threshold.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4372) DMN Editor Data type usability study: design assets
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4372?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4372:
-------------------------------------------
[~aglass][~sarahjane][~karreiro] I added Marvel click-thrus for each Activity, on the now modified test study plan at: https://docs.google.com/document/d/1XZrOn3OtonzMeGirOuaVHeM8vAiACvW_hFuK4...
Please review the click-thrus and let me know if tweaks are needed. There have been some additional design changes.
*Please note in Activity 3 there are two paths to add a row within a nested section that are in place in the prototype (contextual menu & add then drag.)
> DMN Editor Data type usability study: design assets
> ---------------------------------------------------
>
> Key: DROOLS-4372
> URL: https://issues.jboss.org/browse/DROOLS-4372
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Description:
> * Create a study plan outline.
> * Review usability study materials.
> * Create a click-thru wireframe prototype for a lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (SWSQE-854) Increase code coverage above 80% (REST tests)
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-854?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-854:
-------------------------------------
Yes, I will add details when it's simple enough to run it by everyone. It still needs some tweaks to get the coverage. Will add it tomorrow.
> Increase code coverage above 80% (REST tests)
> ---------------------------------------------
>
> Key: SWSQE-854
> URL: https://issues.jboss.org/browse/SWSQE-854
> Project: Kiali QE
> Issue Type: Story
> Reporter: Filip Brychta
> Priority: Major
> Labels: automation
>
> There will be sub task for each package which is not covered at least by 80%
> For each sub task you can:
> * add new tests to increase coverage above 80%
> * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80%
> * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report
> TODO: add description how to check code coverage
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months