Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Tom Nichols
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.
-Tom

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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Niall Pemberton
On 5/22/07, Tom Nichols <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Tom Nichols
Done.   https://issues.apache.org/jira/browse/IO-121

Thanks!
-Tom

On 5/22/07, Niall Pemberton <[hidden email]> wrote:

> On 5/22/07, Tom Nichols <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Tom Nichols
Wow, committed already!  I think that was the easiest patch I've ever
submitted :)

Any speculation on when this might be released?

Thanks.
-Tom

On 5/22/07, Tom Nichols <[hidden email]> wrote:

> Done.   https://issues.apache.org/jira/browse/IO-121
>
> Thanks!
> -Tom
>
> On 5/22/07, Niall Pemberton <[hidden email]> wrote:
> > On 5/22/07, Tom Nichols <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Niall Pemberton
On 5/22/07, Tom Nichols <[hidden email]> 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 <[hidden email]> wrote:
> > Done.   https://issues.apache.org/jira/browse/IO-121
> >
> > Thanks!
> > -Tom
> >
> > On 5/22/07, Niall Pemberton <[hidden email]> wrote:
> > > On 5/22/07, Tom Nichols <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Proposal - Allowing ThesholdingOuputStream to reset written and thresholdExceeded values

Tom Nichols
No problem.  Thanks again!

On 5/22/07, Niall Pemberton <[hidden email]> wrote:

> On 5/22/07, Tom Nichols <[hidden email]> 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 <[hidden email]> wrote:
> > > Done.   https://issues.apache.org/jira/browse/IO-121
> > >
> > > Thanks!
> > > -Tom
> > >
> > > On 5/22/07, Niall Pemberton <[hidden email]> wrote:
> > > > On 5/22/07, Tom Nichols <[hidden email]> 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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