[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
The wildfly instance is reporting a authentication failed with itself
{code:java}
23:56:03,764 WARN [com.arjuna.ats.jta] (Periodic Recovery) XAResourceRecord restored heuristic instance: XAResourceRecord < resource:Subordinate XAResource at http://localhost:8180/wildfly-services, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac100195:773f5f7b:5ffe5f79:60, node_name=1, branch_uid=0:ffffac100195:773f5f7b:5ffe5f79:6c, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.HEURISTIC_HAZARD com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@5e4860e9 > 23:56:03,765 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffffac100195:773f5f7b:5ffe5f79:60 restored heuristic participant XAResourceRecord < resource:Subordinate XAResource at http://localhost:8180/wildfly-services, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac100195:773f5f7b:5ffe5f79:60, node_name=1, branch_uid=0:ffffac100195:773f5f7b:5ffe5f79:6c, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.HEURISTIC_HAZARD com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@5e4860e9 > 23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed
{code}
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5959) BigDecimal_variable % Numeric_value operation causes a compilation error in executable model.
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5959?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5959:
---------------------------------
Sprint: 2020 Week 52-03 (from Dec 21)
> BigDecimal_variable % Numeric_value operation causes a compilation error in executable model.
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-5959
> URL: https://issues.redhat.com/browse/DROOLS-5959
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
> Attachments: reproducer_mc_1b.zip
>
>
> Building a rule written in MVEL dialect like (\*1) using _BigDecimal_variable_ {{%}} _Numeric_value_ operation (\*1-1) in executable rule model, a compilation error (\*2) occurs.
> (\*1)
> {noformat}
> package com.example.reproducer
> import com.example.reproducer.Fact
> dialect "mvel"
> rule "rule1b"
> when
> $fact : Fact( $year : year, (($year % 400) == 0) || ((($year % 4) == 0) && (($year % 100) != 0)), $flag : "YES" ) // ..... (*1-1)
> then
> modify($fact) {
> leapYear = $flag
> }
> System.out.println("***** $fact: " + $fact + ", " + $year + " is a leap year? " + $fact.leapYear);
> end
> {noformat}
> (\*2)
> {noformat}
> [ERROR] /work2/testdir/reproducer_mc_1b/target/generated-sources/drools-model-compiler/main/java/com/example/reproducer/PF6/LambdaPredicateF6282A65CE56BF77478DD6D1D7E1AFE4.java:[17,133] bad operand types for binary operator '%'
> first type: java.math.BigDecimal
> second type: int
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ]
Boris Unckel commented on WFLY-14219:
-------------------------------------
[~smarlow] Please check https://github.com/wildfly/wildfly/pull/13904 for the javax.xml.namespace.QName from [Module "javax.ws.rs.api fix
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFLY-14219
> URL: https://issues.redhat.com/browse/WFLY-14219
> Project: WildFly
> Issue Type: Task
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Boris Unckel
> Priority: Major
> Fix For: 23.0.0.Beta1
>
> Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z
>
>
> There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency.
> List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
> Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5248) [GSS](7.3.z) TCCL should be set to logging custom-handler module
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5248?page=com.atlassian.jira.plug... ]
James Perkins moved JBEAP-20876 to WFCORE-5248:
-----------------------------------------------
Component/s: Logging
(was: Logging)
Fix Version/s: (was: 7.3.6.GA)
Key: WFCORE-5248 (was: JBEAP-20876)
Affects Version/s: (was: 7.3.4.GA)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Project: WildFly Core (was: JBoss Enterprise Application Platform)
> [GSS](7.3.z) TCCL should be set to logging custom-handler module
> ----------------------------------------------------------------
>
> Key: WFCORE-5248
> URL: https://issues.redhat.com/browse/WFCORE-5248
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Attachments: reproducer-overlay.zip
>
>
> When trying to specify the EvaluatorClass where the class exists in the module custom.evaluator , it fails with a ClassNotFound because the TCL is org.jboss.as.standalone instead of custom.evaluator module:
> {code}
> Loader.getTCL return: ModuleClassLoader for Module "org.jboss.as.standalone" from local module loader @6adede5 (finder: local module finder @2d928643 (roots: /tmp/jboss-eap-7.3/modules,/tmp/jboss-eap-7.3/modules/system/layers/base))
> log4j:ERROR Could not instantiate class [org.apache.log4j.asm.INFOLevelEvaluator].
> java.lang.ClassNotFoundException: org.apache.log4j.asm.INFOLevelEvaluator from [Module "org.jboss.log4j.logmanager" version 1.2.0.Final-redhat-00001 from local module loader @6adede5 (finder: local module finder @2d928643 (roots: /tmp/jboss-eap-7.3/modules,/tmp/jboss-eap-7.3/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.apache.log4j.helpers.Loader.loadClass(Loader.java:197)
> at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:326)
> at org.apache.log4j.net.SMTPAppender.setEvaluatorClass(SMTPAppender.java:549)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:298)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:546)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132)
> at java.util.logging.LogManager$3.run(LogManager.java:399)
> at java.util.logging.LogManager$3.run(LogManager.java:396)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
> at java.util.logging.LogManager.access$800(LogManager.java:145)
> at java.util.logging.LogManager$2.run(LogManager.java:345)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
> at java.util.logging.LogManager.getLogManager(LogManager.java:378)
> at org.jboss.modules.Main.main(Main.java:457)
> {code}
> {code}
> <custom-handler name="email" class="org.apache.log4j.net.SMTPAppender" module="custom.evaluator">
> <level name="INFO"/>
> <filter-spec value="match("WFLYSRV0025")"/>
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <properties>
> <property name="EvaluatorClass" value="org.apache.log4j.asm.INFOLevelEvaluator"/>
> ...
> </properties>
> </custom-handler>
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5961) @watch annotation containing "!*" does not work as expected in executable model.
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5961?page=com.atlassian.jira.plug... ]
Mario Fusco moved RHDM-1586 to DROOLS-5961:
-------------------------------------------
Component/s: core engine
executable model
(was: BRE)
Docs QE Status: NEW
Key: DROOLS-5961 (was: RHDM-1586)
QE Status: NEW
Affects Version/s: (was: 7.9.0.GA)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Environment: (was: This issue occurs on RHDM 7.9.0.)
Project: Drools (was: Red Hat Decision Manager)
> @watch annotation containing "!*" does not work as expected in executable model.
> --------------------------------------------------------------------------------
>
> Key: DROOLS-5961
> URL: https://issues.redhat.com/browse/DROOLS-5961
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: reproducer_model_compiler_9b.zip
>
>
> Executing a rule like (\*1) in executable rule model, the rule is evaluated repeatedly. In this rule, re-evaluation occurs in executable model though {{@watch(!\*)}} annotation is specified to the pattern like (\*1-1). {{@watch}} annotation containing {{!\*}} as below does not work as expected, as well as {{@watch(!\*)}}.
> - {{@watch(!\*, point2)}}
> - {{@watch(!\*, point1)}}
> - {{@watch(point1, !\*)}}
> On the other hand, {{@watch}} not containing {{!\*}}, for example, {{@watch(!point1, point2)}} or {{@watch(!point1, point3)}}, works as expected.
> (\*1)
> {noformat}
> package com.example.reproducer
> dialect "mvel"
> rule "rule9b3"
> when
> $fact : Fact( $point1 : point1, $point2 : point2 ) @watch(!*) // ..... (*1-1)
> then
> System.out.println("***** Action of \"rule9b3\" -- $fact = " + $fact + ", $point1 = " + $point1 + ", $point2 = " + $point2);
> $point1 = $point1.add($point2);
> modify($fact) {
> point1 = $point1,
> point3 = $point1
> }
> end
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ]
Boris Unckel edited comment on WFLY-14219 at 1/21/21 10:30 AM:
---------------------------------------------------------------
[~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very clear"javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min.
was (Author: xf01213):
[~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very "javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min.
> Utilize JBoss Modules version 1.9 in module descriptors
> -------------------------------------------------------
>
> Key: WFLY-14219
> URL: https://issues.redhat.com/browse/WFLY-14219
> Project: WildFly
> Issue Type: Task
> Components: Server
> Affects Versions: 22.0.0.Alpha1
> Reporter: Boris Unckel
> Assignee: Boris Unckel
> Priority: Major
> Fix For: 23.0.0.Beta1
>
> Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z
>
>
> There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency.
> List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt
> Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months