Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-2502

Parse must behave properly for reading data from TCP sockets



    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.0.0
    • 3.1.0
    • API, Back End
    • None


      Daffodil assumes the input streams are like files - reads are always blocking for either 1 or more bytes of data, or End-of-data.

      People want to use Daffodil to read data from TCP/IP sockets. These can return 0 bytes from a read because there is no data available, but that does NOT mean the end of data. It's just a temporary condition. More data may come along.

      Daffodil's InputSourceDataInputStream is wrapped around a regular Java input stream, and enables us to support incoming messages which do not conform to byte-boundaries.

      The problem is that there's no way for users to wrap an InputSourceDataInputStream around a TCP/IP socket, and have it behave properly when a read() call temporarily says 0 bytes available.

      Obviously we don't want to sit in a tight loop just retrying the read until we get either some bytes or end-of-data.

      The right API here is that if the read() of the underlying java stream returns 0 bytes, that a hook function supplied by the API user is called.

      One obvious thing a user can do is put a call to Thread.yield() in the hook. (That might even want to be the default behavior if they supply no hook.) Then if they have a separate thread parsing the data with daffodil, that thread will at least yield the CPU, i.e., behave politely in a multi-threaded world.

      More advanced usage could start a Daffodil parse using co-routines, returning control to the caller when the parse must pause due to read() of the Java input stream returning 0 bytes.






            mbeckerle Mike Beckerle
            mbeckerle Mike Beckerle
            0 Vote for this issue
            3 Start watching this issue



              Time Tracking

                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0h
                Time Spent - 1h 20m
                1h 20m