Name: mc57594 Date: 01/28/97


Currently the size of the buffer on PipedInputStream
is fixed at 1024 bytes. If the writer thread exceeds the available
space in the buffer while writing to the pipe, it will block.
It would be nice if there was a way to set the size of the buffer
to allow a larger (or smaller) setting.
  Given a consumer thread that reads input from the PipedInputStream
every (say) hour on the hour, and a producer thread that writes
data to the pipe every hour on the half-hour, if the producer
wanted to write 1025 bytes, it would block for the half hour.
  If the buffer size could be increased, that would allow the
writer to not block
======================================================================
Suggested fix contributed by java.net member leouser:

A DESCRIPTION OF THE FIX :
BUG ID: 4028462 java.io.PipedInputStream: Should be able to set buffer size.
FILES AFFECTED:
java.io.PipedInputStream
JDK VERSION
 jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin

Discusion(embeded in test case as well):
/**
 * BUG ID: 4028462 java.io.PipedInputStream: Should be able to set buffer size.
 * PipedInputStream has a flaw concerning this: the user really has no idea
 * how much data can be shoveled into it. The fields are there as protected
 * items to inspect but you will have to subclass, read the source or use
 * reflection to get at them.
 *
 * Ive chosen to implement this request as a pair of constructors. The alternative
 * is to add public methods to manipulate the storage of the PipedInputStream.
 * This Im not too big of a fan of, it seems a good way to shoot yourself in
 * the foot once the streams are connected. Therefore Ive chosen the configure
 * at creation time pattern, which is what these constructors do. We don't need
 * getters to get at the buffer size because the creator should be able to know
 * how big of a buffer he has created.
 *
 * BENEFITS:
 * 1. Control and knowledge over how much data can be pumped into the
 * PipedInputStream.
 *
 * ANTI-RATIONALE:
 * 1. This functionality can be enabled by simple subclassing. There
 * is nothing stoping a subclasser from creating a constructor like I have done
 * and doing the right steps have a configurable PipedInputStream.
 *
 * IMPACT:
 * I can't see this impacting any existing subclasses too much. Constructors
 * don't have the potential to interfere with methods added in a subclass.
 * Really all we are doing is creating a different byte array and that's it.
 *
 * TESTING STRATEGY:
 * 1. Proved that the new constructors are working. To do this we create
 * 2 sets of PipedInputStream/PipedOutputStream instances and pump data into
 * them until they block. It should be apparent when they block because the
 * output from the writer will suddenly cease.
 *
 * FILES AFFECTED:
 * java.io.PipedInputStream
 *
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 18, 2006
 */

UNIFIED DIFF:
--- /home/nstuff/java6/jdk1.6.0/java/io/PipedInputStream.java Thu Dec 15 02:16:37 2005
+++ /home/javarefs/java/io/PipedInputStream.java Wed Jan 18 09:48:29 2006
@@ -84,6 +84,26 @@
 
     /**
      * Creates a <code>PipedInputStream</code> so
+ * that it is connected to the piped output
+ * stream <code>src</code>. Data bytes written
+ * to <code>src</code> will then be available
+ * as input from this stream. It configures the
+ * buffer size to be equal to the bsize parameter.
+ *
+ * @param src the stream to connect to.
+ * @param bsize the size of the buffer.
+ * @throws IllegalArgumentException if the bsize is < 1.
+ * @exception IOException if an I/O error occurs.
+ */
+ public PipedInputStream(PipedOutputStream src, int bsize) throws IOException {
+ if(bsize < 1)
+ throw new IllegalArgumentException("bsize must be < 1, was " + bsize);
+ buffer = new byte[bsize];
+ connect(src);
+ }
+
+ /**
+ * Creates a <code>PipedInputStream</code> so
      * that it is not yet connected. It must be
      * connected to a <code>PipedOutputStream</code>
      * before being used.
@@ -92,6 +112,24 @@
      * @see java.io.PipedOutputStream#connect(java.io.PipedInputStream)
      */
     public PipedInputStream() {
+ }
+
+ /**
+ * Creates a <code>PipedInputStream</code> so
+ * that it is not yet connected. It must be
+ * connected to a <code>PipedOutputStream</code>
+ * before being used. It configures the buffer
+ * size to be equal to the bsize parameter.
+ *
+ * @param bsize the size of the buffer.
+ * @throws IllegalArgumentException if the bsize is < 1.
+ * @see java.io.PipedInputStream#connect(java.io.PipedOutputStream)
+ * @see java.io.PipedOutputStream#connect(java.io.PipedInputStream)
+ */
+ public PipedInputStream(int bsize) {
+ if(bsize < 1)
+ throw new IllegalArgumentException("bsize < 1, was " + bsize);
+ buffer = new byte[bsize];
     }
 
     /**


JUnit TESTCASE :
import static java.lang.System.out;
import junit.framework.TestCase;
import junit.textui.TestRunner;
import java.util.*;
import java.io.*;

/**
 * BUG ID: 4028462 java.io.PipedInputStream: Should be able to set buffer size.
 * PipedInputStream has a flaw concerning this: the user really has no idea
 * how much data can be shoveled into it. The fields are there as protected
 * items to inspect but you will have to subclass, read the source or use
 * reflection to get at them.
 *
 * Ive chosen to implement this request as a pair of constructors. The alternative
 * is to add public methods to manipulate the storage of the PipedInputStream.
 * This Im not too big of a fan of, it seems a good way to shoot yourself in
 * the foot once the streams are connected. Therefore Ive chosen the configure
 * at creation time pattern, which is what these constructors do. We don't need
 * getters to get at the buffer size because the creator should be able to know
 * how big of a buffer he has created.
 *
 * BENEFITS:
 * 1. Control and knowledge over how much data can be pumped into the
 * PipedInputStream.
 *
 * ANTI-RATIONALE:
 * 1. This functionality can be enabled by simple subclassing. There
 * is nothing stoping a subclasser from creating a constructor like I have done
 * and doing the right steps have a configurable PipedInputStream.
 *
 * IMPACT:
 * I can't see this impacting any existing subclasses too much. Constructors
 * don't have the potential to interfere with methods added in a subclass.
 * Really all we are doing is creating a different byte array and that's it.
 *
 * TESTING STRATEGY:
 * 1. Proved that the new constructors are working. To do this we create
 * 2 sets of PipedInputStream/PipedOutputStream instances and pump data into
 * them until they block. It should be apparent when they block because the
 * output from the writer will suddenly cease.
 *
 * FILES AFFECTED:
 * java.io.PipedInputStream
 *
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 18, 2006
 */
public class TestPipeIS extends TestCase{

    public TestPipeIS(String method){
super(method);
    }

    public class Sleeper extends Thread{

PipedInputStream pis;

public Sleeper(int size){
pis = new PipedInputStream(size);
}

public Sleeper(PipedOutputStream pos, int size){
try{
pis = new PipedInputStream(pos, size);
}
catch(IOException io){
io.printStackTrace();
}
}

public void run(){
while(true){
try{
sleep(1000);
}
catch(InterruptedException io){}
}

}


    }

    public class Blocker extends Thread{

PipedOutputStream pos;
public Blocker(){
pos = new PipedOutputStream();

}
    

public void run(){

long amount = 0L;
String message = "Here comes some bytes";
StringBuilder sb = new StringBuilder();
for(int i = 0; i < 100; i++) sb.append(message);
byte[] data = message.getBytes();
while(true){
out.println("Writing " + data.length + " amount of bytes...");
out.println("Total writen will be " + (amount + data.length));
try{
pos.write(data);
}
catch(IOException io){
io.printStackTrace();
break;
}
amount += data.length;

}


}

    }

    public void testConstructors(){

out.println();
out.println("Testing the PipedInputStream(int bsize) constructor...");
out.println("Watch console, should start to block a little > 10000");
try{
Thread.currentThread().sleep(2000);
}
catch(InterruptedException ie){}
Sleeper sleeper = new Sleeper(10000);
Blocker blocker = new Blocker();
try{
sleeper.pis.connect(blocker.pos);
}
catch(IOException io){
io.printStackTrace();
}
sleeper.start(); blocker.start();
try{
Thread.currentThread().sleep(5000); //let the first batch run...
}
catch(InterruptedException ie){
}

out.println();
out.println("Testing the PipedInputStream(PipedOutputStream, int bsize) constructor...");
out.println("Watch console, should start to block a little > 200");
Blocker blocker2 = new Blocker();
Sleeper sleeper2 = new Sleeper(blocker2.pos, 200);
sleeper2.start(); blocker2.start();

    }







    public static void main(String[] args){

TestPipeIS tpi = new TestPipeIS("testConstructors");
TestRunner.run(tpi);

    }



}


FIX FOR BUG NUMBER:
4028462