potential problems with current parsing approach on java's input stream

[GoogleCodeExporter]

What steps will reproduce the problem?

1.) Call a method on a java object multiple times within a short timespan (e.g. 
using a timer which calls the method n-times approx. each 10ms)

2.) Ensure that the processing of the method call on java side takes 
'considerably' longer than the interval of the calls on air side (e.g. 250ms)

3.) The suggested setup may well lead to a pattern of data transfer from AIR to 
Java, that is currently not correctly handled. See discussion below...

What is the expected output? What do you see instead?

expected: Each of the messages arriving at java's input stream should be parsed 
and processed consecutively i.e. one after the other

but was: Parsing the messages arriving on java's input stream may fail due to 
the current processing of the transferred data in chunks of n=512 bytes. It is 
not guaranteed that the base64-encoded messages enclosed by the start/end 
marker '_'  are correctly parsed with the current approach. Imagine multiple 
consecutive messages arriving like so:

_completeMessage1__part1OfMessage2 = 1st chunk
part2OfMessage_ = 2nd chunk

leads to the following actions

message1: Everything between '_' will be extracted and correctly processed
message2: Cannot be parsed since it's split across two different 512-byte 
chunks. In fact, parts of the data get lost when clearing  StringBuffer and 
tempString within one and the same while-loop run. 
(most likely following data cannot be processed either)

What version of the product are you using? On what operating system?

current source version r96 from SVN on windows vista 32-bit and AIR 2.6

Please provide any additional information below.

Original issue reported on code.google.com by grahs...@gmail.com on 17 Apr 2011 at 5:52

• Merged into: #6

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by khronnuz@gmail.com on 25 Jul 2011 at 5:37

• Changed state: Duplicate