[JBoss JIRA] (DROOLS-1175) Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1175?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1175:
-------------------------------------
Description:
Currently, when summing longs in an accumulate, we get something like this:
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());
{code}
This has 3 problems:
- *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
Support sum(Long):
{code}
when ...
$t : Long(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t);
{code}
and sum(BigDecimal):
{code}
when ...
$t : BigDecimal(...) from accumulate(...,
sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);
{code}
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());
{code}
Not-so-special case 2: to sum integers into a long total, the user should just use:
{code}
$t : Long(...) from accumulate(...,
sum((long) $p.getIntWeight()))
{code}
was:
Currently, when summing longs in an accumulate, we get something like this:
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());
{code}
This has 3 problems:
- *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
Support sum(Long):
{code}
when ...
$t : Long(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t);
{code}
and sum(BigDecimal):
{code}
when ...
$t : BigDecimal(...) from accumulate(...,
sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);
{code}
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());
{code}
Not-so-special case 2: the sum integers into a long total, the user should just use:
{code}
$t : Long(...) from accumulate(...,
sum((long) $p.getIntWeight()))
{code}
> Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
> -------------------------------------------------------------------------
>
> Key: DROOLS-1175
> URL: https://issues.jboss.org/browse/DROOLS-1175
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> Currently, when summing longs in an accumulate, we get something like this:
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t.longValue());
> {code}
> This has 3 problems:
> - *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
> - *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
> - Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
> Solution proposal A) for 7.0 as discussed with Mario:
> Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
> Support sum(Long):
> {code}
> when ...
> $t : Long(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t);
> {code}
> and sum(BigDecimal):
> {code}
> when ...
> $t : BigDecimal(...) from accumulate(...,
> sum($p.getBigDecimalWeight()))
> then scoreHolder.addHard($t);
> {code}
> and also support sum(Integer) and sum(BigInteger).
> If this works well, we can consider it for other functions as well in a different jira issue.
> Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getNumberWeight()))
> then scoreHolder.addHard($t.doubleValue());
> {code}
> Not-so-special case 2: to sum integers into a long total, the user should just use:
> {code}
> $t : Long(...) from accumulate(...,
> sum((long) $p.getIntWeight()))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1175) Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1175?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1175:
-------------------------------------
Description:
Currently, when summing longs in an accumulate, we get something like this:
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());
{code}
This has 3 problems:
- *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
Support sum(Long):
{code}
when ...
$t : Long(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t);
{code}
and sum(BigDecimal):
{code}
when ...
$t : BigDecimal(...) from accumulate(...,
sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);
{code}
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());
{code}
Not-so-special case 2: the sum integers into a long total, the user should just use:
{code}
$t : Long(...) from accumulate(...,
sum((long) $p.getIntWeight()))
{code}
was:
Currently, when summing longs in an accumulate, we get something like this:
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());
{code}
This has 3 problems:
- *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
Support sum(Long):
{code}
when ...
$t : Long(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t);
{code}
and sum(BigDecimal):
{code}
when ...
$t : BigDecimal(...) from accumulate(...,
sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);
{code}
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double)
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());
{code}
Not-so-special case 2: the sum integers into a long total, the user should just use:
{code}
$t : Long(...) from accumulate(...,
sum((long) $p.getIntWeight()))
{code}
> Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
> -------------------------------------------------------------------------
>
> Key: DROOLS-1175
> URL: https://issues.jboss.org/browse/DROOLS-1175
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> Currently, when summing longs in an accumulate, we get something like this:
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t.longValue());
> {code}
> This has 3 problems:
> - *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
> - *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
> - Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
> Solution proposal A) for 7.0 as discussed with Mario:
> Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
> Support sum(Long):
> {code}
> when ...
> $t : Long(...) from accumulate(...,
> sum($p.getLongWeight()))
> then scoreHolder.addHard($t);
> {code}
> and sum(BigDecimal):
> {code}
> when ...
> $t : BigDecimal(...) from accumulate(...,
> sum($p.getBigDecimalWeight()))
> then scoreHolder.addHard($t);
> {code}
> and also support sum(Integer) and sum(BigInteger).
> If this works well, we can consider it for other functions as well in a different jira issue.
> Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
> {code}
> when ...
> $t : Number(...) from accumulate(...,
> sum($p.getNumberWeight()))
> then scoreHolder.addHard($t.doubleValue());
> {code}
> Not-so-special case 2: the sum integers into a long total, the user should just use:
> {code}
> $t : Long(...) from accumulate(...,
> sum((long) $p.getIntWeight()))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1175) Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1175:
----------------------------------------
Summary: Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
Key: DROOLS-1175
URL: https://issues.jboss.org/browse/DROOLS-1175
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
Currently, when summing longs in an accumulate, we get something like this:
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t.longValue());
{code}
This has 3 problems:
- *Loss of precision*: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- *Loss of performance*: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
Support sum(Long):
{code}
when ...
$t : Long(...) from accumulate(...,
sum($p.getLongWeight()))
then scoreHolder.addHard($t);
{code}
and sum(BigDecimal):
{code}
when ...
$t : BigDecimal(...) from accumulate(...,
sum($p.getBigDecimalWeight()))
then scoreHolder.addHard($t);
{code}
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double)
{code}
when ...
$t : Number(...) from accumulate(...,
sum($p.getNumberWeight()))
then scoreHolder.addHard($t.doubleValue());
{code}
Not-so-special case 2: the sum integers into a long total, the user should just use:
{code}
$t : Long(...) from accumulate(...,
sum((long) $p.getIntWeight()))
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1174) Bug of score corruption in dinner party examples uncovered by fix for PLANNER-488
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1174?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1174:
-------------------------------------
Priority: Critical (was: Major)
> Bug of score corruption in dinner party examples uncovered by fix for PLANNER-488
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-1174
> URL: https://issues.jboss.org/browse/DROOLS-1174
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Critical
>
> to reproduce run DinnerPartySolveAllTurtleTest with VM option -DrunTurtleTests=true in optaplanner-examples.
> {code}
> 2016-05-12 16:06:02,121 [main] INFO Opened: data/dinnerparty/unsolved/wedding01.xml
> 2016-05-12 16:06:02,226 [main] TRACE Model annotations parsed for Solution DinnerParty:
> 2016-05-12 16:06:02,226 [main] TRACE Entity SeatDesignation:
> 2016-05-12 16:06:02,226 [main] TRACE Variable seat (genuine)
> 2016-05-12 16:06:03,436 [main] INFO Solving started: time spent (137), best score (144uninitialized/-14400), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
> 2016-05-12 16:06:03,913 [main] DEBUG Custom step (0), time spent (615), score (-2890), new best score (-2890).
> 2016-05-12 16:06:03,913 [main] INFO Custom phase (0) ended: step total (1), time spent (615), best score (-2890), score calculation speed (11050/sec).
> 2016-05-12 16:06:03,937 [main] TRACE Created cachedMoveList: size (10368), moveSelector (Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,941 [main] TRACE Shuffled cachedMoveList with size (10368) in moveSelector(Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,950 [main] TRACE Move index (0), score (-2890), accepted (true), move (Grayson {1.4} <-> Oliver {0.4}).
> 2016-05-12 16:06:03,957 [main] TRACE Move index (1), score (-2890), accepted (true), move (James {10.4} <-> Cameron {10.10}).
> java.lang.IllegalStateException: Score corruption: the workingScore (-3190) is not the uncorruptedScore (-3090) after completedAction (Eliana {8.9} <-> Allison {9.3}):
> The corrupted scoreDirector has 1 ConstraintMatch(s) which are in excess (and should not be there):
> org.optaplanner.examples.dinnerparty.solver/twoSameJobTypePerTable/level0/[8, SOCIALITE]=-100
> The corrupted scoreDirector has no ConstraintMatch(s) which are missing.
> Check your score constraints.
> at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertWorkingScoreFromScratch(AbstractScoreDirector.java:418)
> at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertWorkingScoreFromScratch(DefaultSolverScope.java:118)
> at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertWorkingScoreFromScratch(AbstractPhaseScope.java:156)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:167)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:153)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:125)
> at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:63)
> at org.optaplanner.core.impl.solver.DefaultSolver.runPhases(DefaultSolver.java:229)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.buildAndSolve(SolveAllTurtleTest.java:75)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.runFastAndFullAssert(SolveAllTurtleTest.java:55)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> I enabled trace logging above, it happens in the 3th move of the first step.
> It seems like this rule is responsible:
> {code}
> // 1 democrat and 1 republican = 2 politians at each table but NOT two of the same kind
> // 2 doctors at each table but NOT two of the same kind
> // 2 coaches at each table but NOT two of the same kind
> // 2 programmers at each table but NOT two of the same kind
> // 2 socialites at each table
> // 2 teachers at each table
> rule "twoSameJobTypePerTable"
> when
> $jobType : JobType()
> $table : Table()
> not (
> SeatDesignation(guestJobType == $jobType, seatTable == $table, $leftId : id, $firstJob : guestJob)
> and SeatDesignation(guestJobType == $jobType, seatTable == $table, id > $leftId,
> differentKindIfNeeded($firstJob))
> )
> then
> scoreHolder.addConstraintMatch(kcontext, -100);
> end
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1174) Bug of score corruption in dinner party examples uncovered by fix for PLANNER-488
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1174?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1174:
-------------------------------------
Summary: Bug of score corruption in dinner party examples uncovered by fix for PLANNER-488 (was: Regression score corruption in dinner party probably due PLANNER-488)
> Bug of score corruption in dinner party examples uncovered by fix for PLANNER-488
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-1174
> URL: https://issues.jboss.org/browse/DROOLS-1174
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> to reproduce run DinnerPartySolveAllTurtleTest with VM option -DrunTurtleTests=true in optaplanner-examples.
> {code}
> 2016-05-12 16:06:02,121 [main] INFO Opened: data/dinnerparty/unsolved/wedding01.xml
> 2016-05-12 16:06:02,226 [main] TRACE Model annotations parsed for Solution DinnerParty:
> 2016-05-12 16:06:02,226 [main] TRACE Entity SeatDesignation:
> 2016-05-12 16:06:02,226 [main] TRACE Variable seat (genuine)
> 2016-05-12 16:06:03,436 [main] INFO Solving started: time spent (137), best score (144uninitialized/-14400), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
> 2016-05-12 16:06:03,913 [main] DEBUG Custom step (0), time spent (615), score (-2890), new best score (-2890).
> 2016-05-12 16:06:03,913 [main] INFO Custom phase (0) ended: step total (1), time spent (615), best score (-2890), score calculation speed (11050/sec).
> 2016-05-12 16:06:03,937 [main] TRACE Created cachedMoveList: size (10368), moveSelector (Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,941 [main] TRACE Shuffled cachedMoveList with size (10368) in moveSelector(Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,950 [main] TRACE Move index (0), score (-2890), accepted (true), move (Grayson {1.4} <-> Oliver {0.4}).
> 2016-05-12 16:06:03,957 [main] TRACE Move index (1), score (-2890), accepted (true), move (James {10.4} <-> Cameron {10.10}).
> java.lang.IllegalStateException: Score corruption: the workingScore (-3190) is not the uncorruptedScore (-3090) after completedAction (Eliana {8.9} <-> Allison {9.3}):
> The corrupted scoreDirector has 1 ConstraintMatch(s) which are in excess (and should not be there):
> org.optaplanner.examples.dinnerparty.solver/twoSameJobTypePerTable/level0/[8, SOCIALITE]=-100
> The corrupted scoreDirector has no ConstraintMatch(s) which are missing.
> Check your score constraints.
> at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertWorkingScoreFromScratch(AbstractScoreDirector.java:418)
> at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertWorkingScoreFromScratch(DefaultSolverScope.java:118)
> at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertWorkingScoreFromScratch(AbstractPhaseScope.java:156)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:167)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:153)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:125)
> at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:63)
> at org.optaplanner.core.impl.solver.DefaultSolver.runPhases(DefaultSolver.java:229)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.buildAndSolve(SolveAllTurtleTest.java:75)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.runFastAndFullAssert(SolveAllTurtleTest.java:55)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> I enabled trace logging above, it happens in the 3th move of the first step.
> It seems like this rule is responsible:
> {code}
> // 1 democrat and 1 republican = 2 politians at each table but NOT two of the same kind
> // 2 doctors at each table but NOT two of the same kind
> // 2 coaches at each table but NOT two of the same kind
> // 2 programmers at each table but NOT two of the same kind
> // 2 socialites at each table
> // 2 teachers at each table
> rule "twoSameJobTypePerTable"
> when
> $jobType : JobType()
> $table : Table()
> not (
> SeatDesignation(guestJobType == $jobType, seatTable == $table, $leftId : id, $firstJob : guestJob)
> and SeatDesignation(guestJobType == $jobType, seatTable == $table, id > $leftId,
> differentKindIfNeeded($firstJob))
> )
> then
> scoreHolder.addConstraintMatch(kcontext, -100);
> end
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1174) Regression score corruption in dinner party probably due PLANNER-488
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1174?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1174:
-------------------------------------
Tester: Jiri Locker
> Regression score corruption in dinner party probably due PLANNER-488
> --------------------------------------------------------------------
>
> Key: DROOLS-1174
> URL: https://issues.jboss.org/browse/DROOLS-1174
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> to reproduce run DinnerPartySolveAllTurtleTest with VM option -DrunTurtleTests=true in optaplanner-examples.
> {code}
> 2016-05-12 16:06:02,121 [main] INFO Opened: data/dinnerparty/unsolved/wedding01.xml
> 2016-05-12 16:06:02,226 [main] TRACE Model annotations parsed for Solution DinnerParty:
> 2016-05-12 16:06:02,226 [main] TRACE Entity SeatDesignation:
> 2016-05-12 16:06:02,226 [main] TRACE Variable seat (genuine)
> 2016-05-12 16:06:03,436 [main] INFO Solving started: time spent (137), best score (144uninitialized/-14400), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
> 2016-05-12 16:06:03,913 [main] DEBUG Custom step (0), time spent (615), score (-2890), new best score (-2890).
> 2016-05-12 16:06:03,913 [main] INFO Custom phase (0) ended: step total (1), time spent (615), best score (-2890), score calculation speed (11050/sec).
> 2016-05-12 16:06:03,937 [main] TRACE Created cachedMoveList: size (10368), moveSelector (Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,941 [main] TRACE Shuffled cachedMoveList with size (10368) in moveSelector(Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,950 [main] TRACE Move index (0), score (-2890), accepted (true), move (Grayson {1.4} <-> Oliver {0.4}).
> 2016-05-12 16:06:03,957 [main] TRACE Move index (1), score (-2890), accepted (true), move (James {10.4} <-> Cameron {10.10}).
> java.lang.IllegalStateException: Score corruption: the workingScore (-3190) is not the uncorruptedScore (-3090) after completedAction (Eliana {8.9} <-> Allison {9.3}):
> The corrupted scoreDirector has 1 ConstraintMatch(s) which are in excess (and should not be there):
> org.optaplanner.examples.dinnerparty.solver/twoSameJobTypePerTable/level0/[8, SOCIALITE]=-100
> The corrupted scoreDirector has no ConstraintMatch(s) which are missing.
> Check your score constraints.
> at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertWorkingScoreFromScratch(AbstractScoreDirector.java:418)
> at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertWorkingScoreFromScratch(DefaultSolverScope.java:118)
> at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertWorkingScoreFromScratch(AbstractPhaseScope.java:156)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:167)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:153)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:125)
> at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:63)
> at org.optaplanner.core.impl.solver.DefaultSolver.runPhases(DefaultSolver.java:229)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.buildAndSolve(SolveAllTurtleTest.java:75)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.runFastAndFullAssert(SolveAllTurtleTest.java:55)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> I enabled trace logging above, it happens in the 3th move of the first step.
> It seems like this rule is responsible:
> {code}
> // 1 democrat and 1 republican = 2 politians at each table but NOT two of the same kind
> // 2 doctors at each table but NOT two of the same kind
> // 2 coaches at each table but NOT two of the same kind
> // 2 programmers at each table but NOT two of the same kind
> // 2 socialites at each table
> // 2 teachers at each table
> rule "twoSameJobTypePerTable"
> when
> $jobType : JobType()
> $table : Table()
> not (
> SeatDesignation(guestJobType == $jobType, seatTable == $table, $leftId : id, $firstJob : guestJob)
> and SeatDesignation(guestJobType == $jobType, seatTable == $table, id > $leftId,
> differentKindIfNeeded($firstJob))
> )
> then
> scoreHolder.addConstraintMatch(kcontext, -100);
> end
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1174) Regression score corruption in dinner party probably due PLANNER-488
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1174?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1174:
-------------------------------------
I confirm that the problem has been caused by the fix for PLANNER-488, but I'm still pretty sure that the fix is formally correct. My guess is that the fix uncovered another bug that was somewhat previously hidden. However I'd need a more isolated test case to better investigate this problem.
> Regression score corruption in dinner party probably due PLANNER-488
> --------------------------------------------------------------------
>
> Key: DROOLS-1174
> URL: https://issues.jboss.org/browse/DROOLS-1174
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> to reproduce run DinnerPartySolveAllTurtleTest with VM option -DrunTurtleTests=true in optaplanner-examples.
> {code}
> 2016-05-12 16:06:02,121 [main] INFO Opened: data/dinnerparty/unsolved/wedding01.xml
> 2016-05-12 16:06:02,226 [main] TRACE Model annotations parsed for Solution DinnerParty:
> 2016-05-12 16:06:02,226 [main] TRACE Entity SeatDesignation:
> 2016-05-12 16:06:02,226 [main] TRACE Variable seat (genuine)
> 2016-05-12 16:06:03,436 [main] INFO Solving started: time spent (137), best score (144uninitialized/-14400), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
> 2016-05-12 16:06:03,913 [main] DEBUG Custom step (0), time spent (615), score (-2890), new best score (-2890).
> 2016-05-12 16:06:03,913 [main] INFO Custom phase (0) ended: step total (1), time spent (615), best score (-2890), score calculation speed (11050/sec).
> 2016-05-12 16:06:03,937 [main] TRACE Created cachedMoveList: size (10368), moveSelector (Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,941 [main] TRACE Shuffled cachedMoveList with size (10368) in moveSelector(Shuffling(Filtering(SwapMoveSelector(FromSolutionEntitySelector(SeatDesignation), FromSolutionEntitySelector(SeatDesignation))))).
> 2016-05-12 16:06:03,950 [main] TRACE Move index (0), score (-2890), accepted (true), move (Grayson {1.4} <-> Oliver {0.4}).
> 2016-05-12 16:06:03,957 [main] TRACE Move index (1), score (-2890), accepted (true), move (James {10.4} <-> Cameron {10.10}).
> java.lang.IllegalStateException: Score corruption: the workingScore (-3190) is not the uncorruptedScore (-3090) after completedAction (Eliana {8.9} <-> Allison {9.3}):
> The corrupted scoreDirector has 1 ConstraintMatch(s) which are in excess (and should not be there):
> org.optaplanner.examples.dinnerparty.solver/twoSameJobTypePerTable/level0/[8, SOCIALITE]=-100
> The corrupted scoreDirector has no ConstraintMatch(s) which are missing.
> Check your score constraints.
> at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertWorkingScoreFromScratch(AbstractScoreDirector.java:418)
> at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertWorkingScoreFromScratch(DefaultSolverScope.java:118)
> at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertWorkingScoreFromScratch(AbstractPhaseScope.java:156)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:167)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:153)
> at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:125)
> at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:63)
> at org.optaplanner.core.impl.solver.DefaultSolver.runPhases(DefaultSolver.java:229)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.buildAndSolve(SolveAllTurtleTest.java:75)
> at org.optaplanner.examples.common.app.SolveAllTurtleTest.runFastAndFullAssert(SolveAllTurtleTest.java:55)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> I enabled trace logging above, it happens in the 3th move of the first step.
> It seems like this rule is responsible:
> {code}
> // 1 democrat and 1 republican = 2 politians at each table but NOT two of the same kind
> // 2 doctors at each table but NOT two of the same kind
> // 2 coaches at each table but NOT two of the same kind
> // 2 programmers at each table but NOT two of the same kind
> // 2 socialites at each table
> // 2 teachers at each table
> rule "twoSameJobTypePerTable"
> when
> $jobType : JobType()
> $table : Table()
> not (
> SeatDesignation(guestJobType == $jobType, seatTable == $table, $leftId : id, $firstJob : guestJob)
> and SeatDesignation(guestJobType == $jobType, seatTable == $table, id > $leftId,
> differentKindIfNeeded($firstJob))
> )
> then
> scoreHolder.addConstraintMatch(kcontext, -100);
> end
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6372) Flagging of invalid login credential for datasource is inconsistent.
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6372?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-6372:
-------------------------------
The error of a data-source with the security-domain set-up comes from security subsystem which is in an earlier stage than that JCA gets the JDBC connection. So it won't have the same stack trace on exceptions(if the inconsistent means the stack-trace).
IMO, the problem is that some messages of exception are swallowed when trying to get the credentials from a security-domain, print those messages out will show more useful information.
> Flagging of invalid login credential for datasource is inconsistent.
> --------------------------------------------------------------------
>
> Key: WFLY-6372
> URL: https://issues.jboss.org/browse/WFLY-6372
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Lin Gao
>
> There are multiple parts to this
> (1) If the security-domain is defined for a datasource and the password is invalid, an error is reported in the console which is expected
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <security-domain>encryptedPassword2</security-domain>
> </security>
> </datasource>
> (2) If the 'password' for the datasource is invalid no error is reported in the console log at startup e.g
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>user</user-name>
> <password>passwd</password>
> </security>
> </datasource>
> 3. Whether or not you use a security-domain for a datasource, an invalid 'username' doesn't get flagged in the console.
> Actual results:
> Expected results:
> Invalid username and password should be flagged as login errors in the console log.
> It shouldn't make a difference whether or not you use security-credentials
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months