Ken, What about supplemental characters, the major reason for which Hadoop's Writeable implementations store the length?
On Sun, Aug 25, 2013 at 4:09 PM, Ken Sullivan <[email protected]>wrote: > That could be a possible, but ideally we wouldn't have to change how the > data is being inserted. The data is originally going into accumulo tables > from an existing c++ system with a JNI wrapper to insert a language > independent serialized blob; the code for that is tested and running and > best case scenario we don't have to change it. Checking for EOT and > negative values is working so far...just wondering if there was a an > official list of things to check. > > > On Fri, Aug 23, 2013 at 6:19 PM, Harsh J <[email protected]> wrote: > >> When you're encoding/write()-ing the writable, do you not know the >> length? If you do, store the length first, and you can solve your >> problem? >> >> On Sat, Aug 24, 2013 at 3:58 AM, Ken Sullivan <[email protected]> >> wrote: >> > For my application I'm decoding data in readFields() of >> non-predetermined >> > length. I've found parsing for "4" (ASCII End Of Transmission) or "-1" >> tend >> > to mark the end of the data stream. Is this reliable, or is there a >> better >> > way? >> > >> > Thanks, >> > Ken >> >> >> >> -- >> Harsh J >> > >
