When "com.sun.star.io.TextInputStream" service is used with XInputStream which return partial read (that is reads less bytes than required) from its readSomeBytes com.sun.star.io.TextInputStream assumes that it's a permanent End Of File condition and never attempts to read any data again.

This is an important fault when reading data from dynamic resources built on request like network sockets or similar connections - in may case a remote measuring equipment.

For an example one may attempt to send a request to a server using self made XOutputStream implementation and then may like to retrieve response with com.sun.star.io.TextInputStream.readLine

The com.sun.star.io.TextInputStream.readLine will request readSomeBytes(...., 256), what means it is trying to read some data ahead. Obviously if server response is shorter than that XInputStream  will either timeout or return only what can be returned immediately. The result will be that readSomeBytes will return less bytes than requires. Or even a zero. It doesn't mean link is broken, it just has no more data at the moment.

The current implementation of com.sun.star.io.TextInputStream.readLine fills data in a buffer and detects that this is an eof. I sets mbReachedEOF in TextInputStream.cxx to true.

line 295:
        sal_Int32 nRead = mxStream->readSomeBytes( mSeqSource, nBytesToRead );
        sal_Int32 nTotalRead = nRead;
        if( nRead < nBytesToRead )
            mbReachedEOF = true;

Later any attempt to call implReadString returns without updating buffer 
content due to check in line 214:

  // Already reached EOF? Then we can't read any more
            if( mbReachedEOF )
                break;


Effectively it prevents using TextInputStream to read anything from sources other than a fast, blocking read, local files.

Please, do not make EOF condition permanent. Personally I don't feel capable enough to tinker with this code and fix it. It seems than mbReachedEOF is tested in many places and there is too less comments for me to grasp what's going on.

I mark it as a "major" since this renders this service unusable. A work around is possible by writing own UNO service which doing it correctly.

Best regards,
  Tomasz Sztejka