[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ]
Peter Major edited comment on WFLY-4334 at 4/3/15 8:55 PM:
-----------------------------------------------------------
The test fails for Africa/Cairo timezone, and according to the [timezone informations|http://www.timeanddate.com/time/zone/egypt/cairo] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
was (Author: aldaris):
The test fails for Africa/Cairo timezone, and according to the [http://www.timeanddate.com/time/zone/egypt/cairo|timezone informations] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
> Key: WFLY-4334
> URL: https://issues.jboss.org/browse/WFLY-4334
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Thomas Diesler
> Assignee: David Lloyd
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ]
Peter Major commented on WFLY-4334:
-----------------------------------
The test fails for Africa/Cairo timezone, and according to the [http://www.timeanddate.com/time/zone/egypt/cairo|timezone informations] it looks like there was no 0 o'clock on 2014 August 1st in Egypt... One way to more easily trigger this test failure would be to change "start" in testWithStartInThePast to
{noformat}
start.set(2014, 6, 18);
{noformat}
Since I was unable to reproduce the same build failure with master, I've looked at the code history, which showed that WFLY-3947 has removed this faulty test case. Backporting WFLY-3947 to 8.x resolved the build failures for me.
> CalendarBasedTimeoutTestCase fails consistently
> -----------------------------------------------
>
> Key: WFLY-4334
> URL: https://issues.jboss.org/browse/WFLY-4334
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Thomas Diesler
> Assignee: David Lloyd
>
> Happens on branch 8.x
> {code}
> Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase
> testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE!
> java.lang.AssertionError: Eastern European Time
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539)
> at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-625) Error message in CLI if extension existing on the server is not present in the CLI instalaltion
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-625?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-625:
------------------------------------------
This comes from ExtensionsLoader where the CLI is trying to load CommandHandlers from extension.
I'm wondering if marking this as an error is correct. Maybe a warning should be sufficient.
> Error message in CLI if extension existing on the server is not present in the CLI instalaltion
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-625
> URL: https://issues.jboss.org/browse/WFCORE-625
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: ehsavoie Hugonnet
> Assignee: Alexey Loubyansky
>
> When using the jboss-cli from a WildFly-Core installation to manage a WildFly Full server you get error messages about missing extensions :
> Errors caught while loading extensions:
> 1) Failed to load module org.jboss.as.clustering.infinispan for extension org.jboss.as.clustering.infinispan: org.jboss.as.clustering.infinispan:main
> 2) Failed to load module org.jboss.as.connector for extension org.jboss.as.connector: org.jboss.as.connector:main
> 3) Failed to load module org.jboss.as.ee for extension org.jboss.as.ee: org.jboss.as.ee:main
> 4) Failed to load module org.jboss.as.ejb3 for extension org.jboss.as.ejb3: org.jboss.as.ejb3:main
> 5) Failed to load module org.jboss.as.jaxrs for extension org.jboss.as.jaxrs: org.jboss.as.jaxrs:main
> 6) Failed to load module org.jboss.as.jdr for extension org.jboss.as.jdr: org.jboss.as.jdr:main
> 7) Failed to load module org.jboss.as.jpa for extension org.jboss.as.jpa: org.jboss.as.jpa:main
> 8) Failed to load module org.jboss.as.jsf for extension org.jboss.as.jsf: org.jboss.as.jsf:main
> 9) Failed to load module org.jboss.as.mail for extension org.jboss.as.mail: org.jboss.as.mail:main
> 10) Failed to load module org.jboss.as.naming for extension org.jboss.as.naming: org.jboss.as.naming:main
> 11) Failed to load module org.jboss.as.pojo for extension org.jboss.as.pojo: org.jboss.as.pojo:main
> 12) Failed to load module org.jboss.as.sar for extension org.jboss.as.sar: org.jboss.as.sar:main
> 13) Failed to load module org.jboss.as.security for extension org.jboss.as.security: org.jboss.as.security:main
> 14) Failed to load module org.jboss.as.transactions for extension org.jboss.as.transactions: org.jboss.as.transactions:main
> 15) Failed to load module org.jboss.as.webservices for extension org.jboss.as.webservices: org.jboss.as.webservices:main
> 16) Failed to load module org.jboss.as.weld for extension org.jboss.as.weld: org.jboss.as.weld:main
> 17) Failed to load module org.wildfly.extension.batch for extension org.wildfly.extension.batch: org.wildfly.extension.batch:main
> 18) Failed to load module org.wildfly.extension.bean-validation for extension org.wildfly.extension.bean-validation: org.wildfly.extension.bean-validation:main
> 19) Failed to load module org.wildfly.extension.security.manager for extension org.wildfly.extension.security.manager: org.wildfly.extension.security.manager:main
> 20) Failed to load module org.wildfly.extension.undertow for extension org.wildfly.extension.undertow: org.wildfly.extension.undertow:main
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-625) Error message in CLI if extension existing on the server is not present in the CLI instalaltion
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-625:
----------------------------------------
Summary: Error message in CLI if extension existing on the server is not present in the CLI instalaltion
Key: WFCORE-625
URL: https://issues.jboss.org/browse/WFCORE-625
Project: WildFly Core
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: ehsavoie Hugonnet
Assignee: Alexey Loubyansky
When using the jboss-cli from a WildFly-Core installation to manage a WildFly Full server you get error messages about missing extensions :
Errors caught while loading extensions:
1) Failed to load module org.jboss.as.clustering.infinispan for extension org.jboss.as.clustering.infinispan: org.jboss.as.clustering.infinispan:main
2) Failed to load module org.jboss.as.connector for extension org.jboss.as.connector: org.jboss.as.connector:main
3) Failed to load module org.jboss.as.ee for extension org.jboss.as.ee: org.jboss.as.ee:main
4) Failed to load module org.jboss.as.ejb3 for extension org.jboss.as.ejb3: org.jboss.as.ejb3:main
5) Failed to load module org.jboss.as.jaxrs for extension org.jboss.as.jaxrs: org.jboss.as.jaxrs:main
6) Failed to load module org.jboss.as.jdr for extension org.jboss.as.jdr: org.jboss.as.jdr:main
7) Failed to load module org.jboss.as.jpa for extension org.jboss.as.jpa: org.jboss.as.jpa:main
8) Failed to load module org.jboss.as.jsf for extension org.jboss.as.jsf: org.jboss.as.jsf:main
9) Failed to load module org.jboss.as.mail for extension org.jboss.as.mail: org.jboss.as.mail:main
10) Failed to load module org.jboss.as.naming for extension org.jboss.as.naming: org.jboss.as.naming:main
11) Failed to load module org.jboss.as.pojo for extension org.jboss.as.pojo: org.jboss.as.pojo:main
12) Failed to load module org.jboss.as.sar for extension org.jboss.as.sar: org.jboss.as.sar:main
13) Failed to load module org.jboss.as.security for extension org.jboss.as.security: org.jboss.as.security:main
14) Failed to load module org.jboss.as.transactions for extension org.jboss.as.transactions: org.jboss.as.transactions:main
15) Failed to load module org.jboss.as.webservices for extension org.jboss.as.webservices: org.jboss.as.webservices:main
16) Failed to load module org.jboss.as.weld for extension org.jboss.as.weld: org.jboss.as.weld:main
17) Failed to load module org.wildfly.extension.batch for extension org.wildfly.extension.batch: org.wildfly.extension.batch:main
18) Failed to load module org.wildfly.extension.bean-validation for extension org.wildfly.extension.bean-validation: org.wildfly.extension.bean-validation:main
19) Failed to load module org.wildfly.extension.security.manager for extension org.wildfly.extension.security.manager: org.wildfly.extension.security.manager:main
20) Failed to load module org.wildfly.extension.undertow for extension org.wildfly.extension.undertow: org.wildfly.extension.undertow:main
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-624) Result transformation for composite op failures is broken
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-624:
---------------------------------------
Summary: Result transformation for composite op failures is broken
Key: WFCORE-624
URL: https://issues.jboss.org/browse/WFCORE-624
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Brian Stansberry
CompositeOperationTransformer.CompositeResultTransformer works by analyzing the "step-x" entries in the remote response's "result" node, and then transforming that node.
This breaks down when the failure actually occurs in the remote CompositeOperationHandler, as will be the case if the step refers to a resource or operation that is undefined on that node. In that case there is no "result" node with steps, just a top level failure.
CompositeResultTransformer will actually add a "result" node with the expected error message in this case, but that basically works by luck. And the high level error message for the overall op will no be transformed.
Possible improvements:
1) CompositeOperationHandler sets up a result node in this case, so CompositeResultTransformer can process it.
2) CompositeResultTransformer can try and fix up the top level error message as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-623) ModelControllerClient.Factory lacks some variants
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-623:
------------------------------------
Summary: ModelControllerClient.Factory lacks some variants
Key: WFCORE-623
URL: https://issues.jboss.org/browse/WFCORE-623
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Ladislav Thon
Assignee: Ladislav Thon
In the {{ModelControllerClient.Factory}} class, each factory method in fact has two varians: with a {{protocol}} as a first parameter, and without it. There are two exceptions -- two methods are lacking a {{protocol}}-less variant:
- {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions)}}
- {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions, final String clientBindAddress)}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-315 at 4/3/15 8:23 AM:
-----------------------------------------------------------------
Hey Edson,
What's the status of this issue? Do we have sumInt(), sumLong(), sumBigDecimal() available in Drools?
Or better yet, support for overloaded methods support, so sum(int), sum(long), sum(BigDecimal) just do the right thing (instead of using sum(double)).
was (Author: ge0ffrey):
Edson,
What's the status of this issue? Do we have sumInt(), sumLong(), sumBigDecimal() available yet in Drools?
Or better yet, overloaded methods support, so sum(int), sum(long), sum(BigDecimal) just do the right thing (instead of using sum(double))?
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> {code}
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
{code}
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
{code}
was:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> {code}
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
*Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
was:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> *Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
> Old description:
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
was:
*Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months