StreamingAssembler doesn't update the available bytes as bytes are read

[GoogleCodeExporter]

StreamingAssembler doesn't update the number of available bytes as bytes are 
read from
the given buffer.

What steps will reproduce the problem?
1. Create a BufferReceiver that uses StreamingAssembler.
2. Set waitForCompleteMessage to true.
3. Create a buffer that contains a message and half with the FAST header (i.e. 
block size).
4. Make sure that the size of the second message is smaller than the size of 
the given buffer.
5. Add the buffer to the receiver.

What is the expected output? What do you see instead?
The receiver decodes the first message and waits for the rest of the second
message. Instead, the decoder will try decoding the second message which results
in an EOF exception.

What version of the product are you using (svn Rev # or download package
version #)? On what operating system?  What source of data
quickfast_lnx_src_1_3

Please provide any additional information below.   Attach templates and
test data if possible and relevant.
Attached is a patch for the bug.

Original issue reported on code.google.com by jvsha...@gmail.com on 20 Aug 2011 at 8:12

Attachments:

• 0001-Fixed-a-bug-in-the-QuickFAST-library.patch

[GoogleCodeExporter]

The problem is real, but the patch doesn't fix it.

The StreamingAssembler used to be responsible for maintaining the position in 
the current buffer, but that was changed.  The DataSource now maintains this 
position.  The StreamingAssembler needs to ask DataSource how much data is left 
in the current buffer.

I've added a new method, currentBytesAvailable, to DataSource to get this 
information and changed StreamingAssembler to use it.

I'll update this issue again when the fix is available in the repository.

Original comment by dale.wil...@gmail.com on 28 Sep 2011 at 8:24

• Changed state: Accepted

[GoogleCodeExporter]

Fixed in R510

Original comment by dale.wil...@gmail.com on 28 Sep 2011 at 8:43

[GoogleCodeExporter]

Original comment by dale.wil...@gmail.com on 28 Sep 2011 at 8:43

• Changed state: Fixed

[GoogleCodeExporter]

Can you explain why calling getBuffer() is a bad idea. This seems to be the 
only difference between currentBytesAvailable and bytesAvailable.

Original comment by jvsha...@gmail.com on 2 Oct 2011 at 10:49

[GoogleCodeExporter]

1: bytesAvailable() is virtual.  It would be possible for a derived class to 
override it and there is nothing in it's "contract" to prevent it from blocking 
waiting for a new incoming buffer.

In fact the default bytesAvailable() calls getBuffer()

2: getBuffer() is pure virtual so the derived class must override it. There is 
nothing to prevent the derived class from blocking.  In fact it seems 
reasonable that an implementation of getBuffer() might block waiting for a new 
buffer to arrive -- and some of them do. 

However the serviceQueue() method must not block at this point waiting for a 
new buffer to arrive.  The thread calling serviceQueue is the one accepting 
incoming buffers so an arriving buffer would never get noticed because the 
servicing thread is busy.

Original comment by dale.wil...@gmail.com on 3 Oct 2011 at 4:08

[GoogleCodeExporter]

Makes perfect sense. Thanks for taking the time to clarify things.

Original comment by jvsha...@gmail.com on 3 Oct 2011 at 5:24