I was going to suggest that yesterday but declined due to the risk and overall
complexity of an additional switch.

----- Original Message -----
> From: "Robbie Gemmell" <[email protected]>
> To: "Andrew Stitcher" <[email protected]>
> Cc: "Robbie Gemmell" <[email protected]>, "Cliff Jansen" 
> <[email protected]>, "qpid" <[email protected]>
> Sent: Thursday, August 4, 2016 12:28:17 PM
> Subject: Re: Review Request 50759: Force periodic cleanup of EpollPoller 
> memory
> 
> 
> -----------------------------------------------------------
> 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
> > 
> >
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to