[JBoss JIRA] (JBRULES-3546) Planner: Late acceptance and great deluge get stuck in an endless move iterator loop because there are no acceptable moves
1:55 a.m.
[
https://issues.jboss.org/browse/JBRULES-3546?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3546:
-------------------------------------------
Possible ways to deal with this issue:
- check the termination at every move and benchmark the performance impact. Possibly check
the termination condition only once every 100 moves.
- support to specify maximumSelection (as opposed to minimumAcceptedSelection it includes
non-accepted moves too)
Planner: Late acceptance and great deluge get stuck in an endless
move iterator loop because there are no acceptable moves
--------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3546
URL: https://issues.jboss.org/browse/JBRULES-3546
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Minor
Tabu search and simulated annealing don't suffer from this, because they always find
acceptable move(s) sooner or later (TS because it accepts anything that isn't tabu and
SA because every move has a change of being acceptable no matter what).
Late acceptance or great deluge with a moveSelector that is neverEnding (or too big to be
called ending), will result in a never ending Solver because the Termination isn't
checked in the move iterator (which it should... even if that results in a performance
cost :( ).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:54 a.m.
[
https://issues.jboss.org/browse/JBRULES-3546?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3546:
-------------------------------------------
The performance cost is not significant enough to not check it in the lower loops too:
{code}
Before with 10 seconds spend
2012-07-27 09:50:34,334 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1674), time spend (10004), best score (0hard/-296607971soft).
2012-07-27 09:50:34,334 [pool-2-thread-1] INFO Solving ended: time spend (10004), best
score (0hard/-296607971soft), average calculate count per second (168900).
2012-07-27 09:51:07,125 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1655), time spend (10002), best score (0hard/-296655732soft).
2012-07-27 09:51:07,125 [pool-2-thread-1] INFO Solving ended: time spend (10002), best
score (0hard/-296655732soft), average calculate count per second (167017).
2012-07-27 09:51:29,184 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1705), time spend (10002), best score (0hard/-296517041soft).
2012-07-27 09:51:29,184 [pool-2-thread-1] INFO Solving ended: time spend (10002), best
score (0hard/-296517041soft), average calculate count per second (172060).
After with 10 seconds spend
2012-07-27 09:51:54,711 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1627), time spend (10000), best score (0hard/-296670512soft).
2012-07-27 09:51:54,711 [pool-2-thread-1] INFO Solving ended: time spend (10000), best
score (0hard/-296670512soft), average calculate count per second (164218).
2012-07-27 09:52:16,561 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1601), time spend (10000), best score (0hard/-296695553soft).
2012-07-27 09:52:16,561 [pool-2-thread-1] INFO Solving ended: time spend (10000), best
score (0hard/-296695553soft), average calculate count per second (161578).
2012-07-27 09:52:36,198 [pool-2-thread-1] INFO Phase localSearch ended: step total
(1617), time spend (10000), best score (0hard/-296695051soft).
2012-07-27 09:52:36,198 [pool-2-thread-1] INFO Solving ended: time spend (10000), best
score (0hard/-296695051soft), average calculate count per second (163213).
{code}
Planner: Late acceptance and great deluge get stuck in an endless
move iterator loop because there are no acceptable moves
--------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3546
URL: https://issues.jboss.org/browse/JBRULES-3546
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Minor
Tabu search and simulated annealing don't suffer from this, because they always find
acceptable move(s) sooner or later (TS because it accepts anything that isn't tabu and
SA because every move has a change of being acceptable no matter what).
Late acceptance or great deluge with a moveSelector that is neverEnding (or too big to be
called ending), will result in a never ending Solver because the Termination isn't
checked in the move iterator (which it should... even if that results in a performance
cost :( ).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:42 a.m.
[
https://issues.jboss.org/browse/JBRULES-3546?page=com.atlassian.jira.plug...
]
Geoffrey De Smet resolved JBRULES-3546.
---------------------------------------
Fix Version/s: 5.5.0.Beta1
Resolution: Done
Fixed
Planner: Late acceptance and great deluge get stuck in an endless
move iterator loop because there are no acceptable moves
--------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3546
URL: https://issues.jboss.org/browse/JBRULES-3546
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Minor
Fix For: 5.5.0.Beta1
Tabu search and simulated annealing don't suffer from this, because they always find
acceptable move(s) sooner or later (TS because it accepts anything that isn't tabu and
SA because every move has a change of being acceptable no matter what).
Late acceptance or great deluge with a moveSelector that is neverEnding (or too big to be
called ending), will result in a never ending Solver because the Termination isn't
checked in the move iterator (which it should... even if that results in a performance
cost :( ).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:44 a.m.
[
https://issues.jboss.org/browse/JBRULES-3546?page=com.atlassian.jira.plug...
]
Geoffrey De Smet edited comment on JBRULES-3546 at 7/27/12 7:42 AM:
--------------------------------------------------------------------
Fixed by checking the termination condition in every move: performance impact is
ignorable.
was (Author: ge0ffrey):
Fixed
Planner: Late acceptance and great deluge get stuck in an endless
move iterator loop because there are no acceptable moves
--------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3546
URL: https://issues.jboss.org/browse/JBRULES-3546
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Minor
Fix For: 5.5.0.Beta1
Tabu search and simulated annealing don't suffer from this, because they always find
acceptable move(s) sooner or later (TS because it accepts anything that isn't tabu and
SA because every move has a change of being acceptable no matter what).
Late acceptance or great deluge with a moveSelector that is neverEnding (or too big to be
called ending), will result in a never ending Solver because the Termination isn't
checked in the move iterator (which it should... even if that results in a performance
cost :( ).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4487
days inactive
4527
days old
4 comments
1 participants
participants (1)
-
Geoffrey De Smet (JIRA)