[
https://issues.apache.org/jira/browse/THRIFT-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Reiss resolved THRIFT-469.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.2
> TimerManager::add() bug when new timeout < current timeout
> ----------------------------------------------------------
>
> Key: THRIFT-469
> URL: https://issues.apache.org/jira/browse/THRIFT-469
> Project: Thrift
> Issue Type: Bug
> Components: Library (C++)
> Affects Versions: 0.1
> Environment: Mac OS X 10.5.6
> Reporter: Rush Manbert
> Fix For: 0.2
>
> Attachments: TimerManagerPatchJira469.txt,
> TimerManagerTestsPatchJira469.txt
>
>
> The function:
> void TimerManager::add(shared_ptr<Runnable> task, int64_t timeout)
> inserts the new task into the taskMap_, then executes this code:
> if (taskCount_ == 1 || timeout < taskMap_.begin()->first) {
> monitor_.notify();
> }
> which doesn't call monitor_.notify() when the new task's timeout is < the
> current timeout, because the timeout portion of the test ends up testing
> timeout against itself.
> The TimerManagerTests::test00 doesn't reveal this problem when
> concurrency_test is built as part of the normal make. That's because there is
> a race between the TimerManager dispatcher starting and the test inserting
> the two test tasks. If the test delays for 1 second after adding orphanTask,
> then the test fails every time, because the dispatcher never gets broken out
> of the 10 second sleep he starts when orphanTask was inserted. I saw the
> error because I built a debug version of concurrency_test, which changed the
> timing enough to reveal the bug.
> I will attach patches for both the test and TimerManager.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
