Re: Pausing POE::Wheel::FollowTail?

Hi, Craig.

The feature seems useful (and practical to implement) as you've  
described it.  Jordan's concern is also valid, but it can be addressed  
by watching for rotation while the wheel is suspended.  I'll apply  
this feature as long as the caveats are clearly documented.

-- 
Rocco Caputo - [email protected]


On Oct 7, 2008, at 12:06, Votava, Craig M (Craig) wrote:

> Hi Rocco-
>
> Thanks for your thoughts on this. My view of the functionality of  
> pause
> (although now that I think of it, maybe suspend would be a better  
> word)
> is as follows:
>
> When FollowTail is suspended, no buffering takes place. The current
> location in the current file is preserved and if FollowTail is resumed
> before any reset occurs, things proceed from that point. Otherwise the
> output resumes from the beginning of the currently active file  
> (possibly
> providing an indication of skipped data?).
>
> I don't have a problem implementing this, the real question is would
> enough people find this suspend functionality useful enough that it
> should be made part of the FollowTail module, or is this just  
> something
> that I find useful but not many others?
>
> Thanks
>
> -Craig
>
> -----Original Message-----
> From: Rocco Caputo [mailto:[email protected]]
> Sent: Monday, October 06, 2008 8:03 PM
> To: POE Mailing List
> Subject: Re: Pausing POE::Wheel::FollowTail?
>
> Pausing anything that tails a file is problematic.  What happens if
> the user goes away for lunch, a weekend, or vacation, and the log file
> rolls over more than once before they return?
>
> A reliable solution would be to not pause.  Rather, the wheel or
> application would buffer changes until output is resumed.  Buffered
> data would need to be spooled to disk to avoid memory limits.  And
> then there's the chance of running out of disk if the user's gone for
> a few weeks.
>
> A compromise might be to provide a certain amount of scrollback, and
> let the user browse around until their data scrolls away.  While the
> Tk text window is focused on historical information, it will track
> that position as it continues to scroll.  The user would be forced to
> resume scrolling when their historical place reaches the end of the
> scrollback buffer.
>
> The most reliable solution would be to stop whatever generates log
> output until the user is ready to resume.  For example, pause could
> run system("apachectl stop"), and resume could run system("apachectl
> start").  That way you can be fairly certain the file won't change
> while the viewer isn't looking. :)
>
> -- 
> Rocco Caputo - [email protected]