[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when closures.
by xb l (Jira)
[ https://issues.redhat.com/browse/DROOLS-4902?page=com.atlassian.jira.plug... ]
xb l updated DROOLS-4902:
-------------------------
Description:
When I study drools , I write a rule use divide operator
{code:java}
rule "Buzz" salience 2
when
$n: Number( this / 5 == 3 )
then
System.out.println("Buzz");
end
{code}
It's OK.
But:
{code:java}
rule "Buzz" salience 2
when
$n: Number( this % 5 == 0 )
then
System.out.println("Buzz");
end
{code}
Report parser error: Unable to Analyse Expression this % 5 == 0:
The drools document mentioned the same example:
Person( age > 100 && ( age % 10 == 0 ) )
% is Multiplicative operators, why parser error?
was:
When I study drools , I write a rule use divide operator
{code:java}
rule "Buzz" salience 2
when
$n: Number( this / 5 == 3 )
then
System.out.println("Buzz");
end
{code}
It's OK.
But:
{code:java}
rule "Buzz" salience 2
when
$n: Number( this % 5 == 0 )
then
System.out.println("Buzz");
end
{code}
Report parser error: Unable to Analyse Expression this % 5 == 0:
> Can not use mod operators (%) in when closures.
> -----------------------------------------------
>
> Key: DROOLS-4902
> URL: https://issues.redhat.com/browse/DROOLS-4902
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: xb l
> Assignee: Mario Fusco
> Priority: Major
>
> When I study drools , I write a rule use divide operator
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this / 5 == 3 )
> then
> System.out.println("Buzz");
> end
> {code}
> It's OK.
> But:
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this % 5 == 0 )
> then
> System.out.println("Buzz");
> end
> {code}
> Report parser error: Unable to Analyse Expression this % 5 == 0:
> The drools document mentioned the same example:
> Person( age > 100 && ( age % 10 == 0 ) )
> % is Multiplicative operators, why parser error?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when clouse.
by xb l (Jira)
[ https://issues.redhat.com/browse/DROOLS-4902?page=com.atlassian.jira.plug... ]
xb l updated DROOLS-4902:
-------------------------
Summary: Can not use mod operators (%) in when clouse. (was: Can not use mod operators (%) in when closures.)
> Can not use mod operators (%) in when clouse.
> ---------------------------------------------
>
> Key: DROOLS-4902
> URL: https://issues.redhat.com/browse/DROOLS-4902
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: xb l
> Assignee: Mario Fusco
> Priority: Major
>
> When I study drools , I write a rule use divide operator
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this / 5 == 3 )
> then
> System.out.println("Buzz");
> end
> {code}
> It's OK.
> But:
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this % 5 == 0 )
> then
> System.out.println("Buzz");
> end
> {code}
> Report parser error: Unable to Analyse Expression this % 5 == 0:
> The drools document mentioned the same example:
> Person( age > 100 && ( age % 10 == 0 ) )
> % is Multiplicative operators, why parser error?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-12913?page=com.atlassian.jira.plugi... ]
Lin Gao edited comment on WFLY-12913 at 1/6/20 5:38 AM:
--------------------------------------------------------
+com.sun.istack+ comes from [istack-commons repository|https://github.com/eclipse-ee4j/jaxb-istack-commons/tree/maste...], which is different than the jaxb-ri one. The version is different as well.
The version of +com.sun.istack+ used by WildFly is +3.0.7+, looks like we need to upgrade it as well(to 3.0.10) together with jaxb-ri.
was (Author: gaol):
+com.sun.istack+ comes from [istack-commons repository|https://github.com/eclipse-ee4j/jaxb-istack-commons/tree/maste...], which is different than the jaxb-ri one. The version is different as well.
The version of +com.sun.istack+ used by WildFly is +3.0.7+, looks like we need to upgrade it as well together with jaxb-ri.
> Rationalize com.sum.xml.bind module dependencies
> ------------------------------------------------
>
> Key: WFLY-12913
> URL: https://issues.redhat.com/browse/WFLY-12913
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate, REST, Web Services
> Reporter: Brian Stansberry
> Assignee: Lin Gao
> Priority: Minor
>
> The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents:
> {code}
> <module name="com.github.relaxng" export="true" />
> <module name="com.sun.istack" export="true" />
> <module name="com.sun.xml.txw2" export="true" />
> <module name="com.sun.xsom" export="true" />
> {code}
> Task is to:
> 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules.
> 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules.
> 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFLY-12913) Rationalize com.sum.xml.bind module dependencies
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-12913?page=com.atlassian.jira.plugi... ]
Lin Gao commented on WFLY-12913:
--------------------------------
+com.sun.istack+ comes from [istack-commons repository|https://github.com/eclipse-ee4j/jaxb-istack-commons/tree/maste...], which is different than the jaxb-ri one. The version is different as well.
The version of +com.sun.istack+ used by WildFly is +3.0.7+, looks like we need to upgrade it as well together with jaxb-ri.
> Rationalize com.sum.xml.bind module dependencies
> ------------------------------------------------
>
> Key: WFLY-12913
> URL: https://issues.redhat.com/browse/WFLY-12913
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate, REST, Web Services
> Reporter: Brian Stansberry
> Assignee: Lin Gao
> Priority: Minor
>
> The com.sun.xml.bind module depends on and exports four other modules, and those modules in turn are private and have no other dependents:
> {code}
> <module name="com.github.relaxng" export="true" />
> <module name="com.sun.istack" export="true" />
> <module name="com.sun.xml.txw2" export="true" />
> <module name="com.sun.xsom" export="true" />
> {code}
> Task is to:
> 1) Write to wildfly-dev mail list to check for any projects that layer on WildFly that directly use these modules.
> 2) Write to jboss-layered-products (internal Red Hat) mail list to check for any products based on WF/EAP that directly use these modules.
> 3) Assuming no positive responses, make the artifacts from the above four modules direct artifacts of the com.sun.xml.bind module, add any needed module dependencies to con.sum.xml.bind, and get rid of those four modules.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (JGRP-2429) MsgStats num_bytes_sent should be incremented by the Message::size
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-2429?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-2429:
------------------------------------
[~belaban] is the fact that "number of bytes sent" means "number of payload bytes sent" documented anywhere?
I'm pretty sure in {{doSend()}} {{length}} is the number of actual bytes sent, **not** the payload length.
> MsgStats num_bytes_sent should be incremented by the Message::size
> ------------------------------------------------------------------
>
> Key: JGRP-2429
> URL: https://issues.redhat.com/browse/JGRP-2429
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Major
> Fix For: 4.1.9
>
>
> MsgStats num_bytes_sent should be incremented by the Message::size
> Today it is incremented by the Message:length that is the length of the payload, it doesn't include the headers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4902) Can not use mod operators (%) in when closures.
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4902?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4902:
--------------------------------
Sprint: 2020 Week 01-03 (from Dec 30)
> Can not use mod operators (%) in when closures.
> -----------------------------------------------
>
> Key: DROOLS-4902
> URL: https://issues.redhat.com/browse/DROOLS-4902
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.31.0.Final
> Reporter: xb l
> Assignee: Mario Fusco
> Priority: Major
>
> When I study drools , I write a rule use divide operator
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this / 5 == 3 )
> then
> System.out.println("Buzz");
> end
> {code}
> It's OK.
> But:
> {code:java}
> rule "Buzz" salience 2
> when
> $n: Number( this % 5 == 0 )
> then
> System.out.println("Buzz");
> end
> {code}
> Report parser error: Unable to Analyse Expression this % 5 == 0:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ]
Jean Francois Denise updated WFCORE-4785:
-----------------------------------------
Attachment: after-reload.hprof
> PathAddress leaked on reload
> ----------------------------
>
> Key: WFCORE-4785
> URL: https://issues.redhat.com/browse/WFCORE-4785
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Jean Francois Denise
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml
>
>
> Boot server, connect CLI and reload.
> As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak).
> Attached heapdump, server.log and configuration used (reduced standalone.xml).
> server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization.
> server.log contains stacktrace of PathAddress allocation.
> You will notice:
> 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface.
> 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized.
> 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149.
> 4) We have 3 remaining PathAddress 149, 600 and 789
> 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218.
> So we have a leak of 1 PathAddress instance, instance 149.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ]
Jean Francois Denise updated WFCORE-4785:
-----------------------------------------
Attachment: nominal.hprof
> PathAddress leaked on reload
> ----------------------------
>
> Key: WFCORE-4785
> URL: https://issues.redhat.com/browse/WFCORE-4785
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Jean Francois Denise
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml
>
>
> Boot server, connect CLI and reload.
> As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak).
> Attached heapdump, server.log and configuration used (reduced standalone.xml).
> server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization.
> server.log contains stacktrace of PathAddress allocation.
> You will notice:
> 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface.
> 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized.
> 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149.
> 4) We have 3 remaining PathAddress 149, 600 and 789
> 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218.
> So we have a leak of 1 PathAddress instance, instance 149.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ]
Jean Francois Denise updated WFCORE-4785:
-----------------------------------------
Attachment: server.log
> PathAddress leaked on reload
> ----------------------------
>
> Key: WFCORE-4785
> URL: https://issues.redhat.com/browse/WFCORE-4785
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Jean Francois Denise
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml
>
>
> Boot server, connect CLI and reload.
> As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak).
> Attached heapdump, server.log and configuration used (reduced standalone.xml).
> server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization.
> server.log contains stacktrace of PathAddress allocation.
> You will notice:
> 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface.
> 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized.
> 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149.
> 4) We have 3 remaining PathAddress 149, 600 and 789
> 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface.
> 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218.
> So we have a leak of 1 PathAddress instance, instance 149.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months