----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50759/#review144779 -----------------------------------------------------------
I haven't even looked at the diff, but regarding the comments around what time period to choose: would making it configurable be useful so folks can pick appropriately to their scenario be resonable? I have no idea how much work that would be it has to be said. Feel free to ignore these peanut gallery comments :) - Robbie Gemmell On Aug. 4, 2016, 3:32 a.m., Cliff Jansen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50759/ > ----------------------------------------------------------- > > (Updated Aug. 4, 2016, 3:32 a.m.) > > > Review request for qpid and Andrew Stitcher. > > > Bugs: qpid-7373 > https://issues.apache.org/jira/browse/qpid-7373 > > > Repository: qpid-cpp > > > Description > ------- > > If a C++ broker is lightly loaded with many short lived connections such that > at least one worker thread remains unwoken from the epoll_wait, its > DeletionManager::ThreadStatus::handles grows without bound and the associated > handles retain a shared_ptr ref and never go away. > > This patch allows IO threads a maximum of one minute to accumulate > DeletionManager shared pointer references before resuming the wait loop which > involves calling > > PollerHandleDeletionManager.markAllUnusedInThisThread(); > > The overhead is small on brokers light thread load and non-existent on busy > brokers. > > > Diffs > ----- > > src/qpid/sys/epoll/EpollPoller.cpp 6fdf996 > > Diff: https://reviews.apache.org/r/50759/diff/ > > > Testing > ------- > > Jira test case, PollerTest.cpp > > > Thanks, > > Cliff Jansen > >
