commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values
Date Tue, 22 May 2007 19:43:20 GMT
On 5/22/07, Tom Nichols <tmnichols@gmail.com> wrote:
> Wow, committed already!  I think that was the easiest patch I've ever
> submitted :)
>
> Any speculation on when this might be released?

Difficult to say - since this was the first change for 1.4, so it will
probably be a while before there is motivation for a new release. I
could ask the IO 1.3.2 release manager if he minds me porting it to
the 1.3 branch (so that it makes 1.3.2) but unless he agrees it could
be a while.

btw I just renamed the method to resetByteCount() to make it more
explict what its function is.

Niall

> Thanks.
> -Tom
>
> On 5/22/07, Tom Nichols <tmnichols@gmail.com> wrote:
> > Done.   https://issues.apache.org/jira/browse/IO-121
> >
> > Thanks!
> > -Tom
> >
> > On 5/22/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > > On 5/22/07, Tom Nichols <tmnichols@gmail.com> wrote:
> > > > Hi --
> > > >
> > > > I wanted to use ThresholdingOutputStream to basically split output
> > > > over multiple files when a byte count is reached (Similar to a rolling
> > > > file log).  I could do this easily by implementing thresholdReached().
> > > >  The method would close the current stream, create a new stream, and
> > > > then reset the written and thresholdExceeded values.  The problem, of
> > > > course, is that I can't change the values of written and
> > > > thresholdExceeded.  Basically I want to be able to hit a byte
> > > > threshold multiple times instead of just once.
> > > >
> > > > In order to do the same thing with the current implementation, I need
> > > > to override checkThreshold( int ) and then try to keep track of how
> > > > many bytes were written to all previous output streams:
> > > >     protected void checkThreshold(int count) throws IOException
> > > >     {
> > > >         if ( getByteCount() - writtenToPreviousStreams + count > threshold
)
> > > >         {
> > > >             writtenToPreviousStreams = getByteCount();
> > > >             //switch to new output stream
> > > >         }
> > > >     }
> > > >
> > > > And I would have to override isThresholdExceeded() otherwise it would
> > > > return true even though it is not true for the current stream. And
> > > > then thresholdReached() is never called and has to be an empty method.
> > > >  So you can see this becomes a little more cumbersome.
> > > >
> > > > So would there be any problems with adding:
> > > > protected setThresholdExceeded( boolean thresholdExceeded ) and
> > > > setByteCount( long written )
> > > > or maybe just a protected reset() method?
> > > >
> > > > The only other change that would need to be made: currently in
> > > > checkThreshold(int), thresholdExceeded needs to be set to true before
> > > > the call to thresholdReached() so that the value may be reset to false
> > > > inside thresholdReached().  But this should not cause any problem
> > > > AFAIK since thresholdExceeded is private anyway.
> > > >
> > > >   protected void checkThreshold(int count) throws IOException
> > > >   {
> > > >     if (!thresholdExceeded && (written + count > threshold))
> > > >     {
> > > >       thresholdExceeded = true; //this was previously set after the
> > > > thresholdReached() call
> > > >       thresholdReached();
> > > >     }
> > > >   }
> > > >
> > > > Any comments?  Thanks.
> > >
> > > Adding setters for thresholdExceeded and byteCount is allowing people
> > > to shoot themselves in the foot IMO - but I think reset() is a good
> > > idea. Best thing is to create a Jira ticket for this:
> > >
> > > http://jakarta.apache.org/commons/io/issue-tracking.html
> > >
> > > Niall
> > >
> > > > -Tom
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message