MRN TRNA message buffer size

Many times, in a single fragment message, the expected size (fid="32480" name="TOT_SIZE") has smaller value than buffer size (fid="32641" name="FRAGMENT"), is it normal?

where fieldEntry is a FieldEntry object with fid 32641.

ntaBuffer = fieldEntry.buffer().bufer().array();

example

Expected total buffer size: 1457 current size: 1944

Sort by:
1 - 1 of 11
    User: "zoya faberov"
    ✭✭✭✭✭
    Accepted Answer

    Please be updated:

    The API development team found the fix for this issue.
    They suggest you use the fieldEntry.buffer().buffer().limit()
    instead of fieldEntry.buffer().buffer().array().length to get a proper size of full
    used OMMBuffer amount.

    Example:

    From:

    if((fieldEntry.buffer().buffer().array().length
    > totalSize) && (totalSize > 0)){

    To:

    if((fieldEntry.buffer().buffer().limit() >
    totalSize) && (totalSize > 0)){

    The development team confirms this is API usage issues in
    the example application. In between 1.0.2 and 1.0.5, EMA was enhanced to
    internally pool created objects to avoid garbage collection. The current EMA
    implementation is reusing pooled OmmBuffer objects. The
    OmmBuffer.buffer().array().length returns the full capacity length instead of
    the full used amount while the OmmBuffer.buffer().limit() returns the used size
    value.

    In addition, when reassembling the fragments back, please also be mindful of the limit, and use:

    ...
    ByteArrayOutputStream fragOutputStream = new
    ByteArrayOutputStream( );

    for(int i = 0; i < alFrags.size(); i++) {
    try {
    fragOutputStream.write( alFrags.get(i).array(),0, alFrags.get(i).limit());
    } catch(Exception e) {}

    }

    strFlatFrag+= unzipPayload(fragOutputStream.toByteArray());
    ...

    For an updated complete example please see Streaming Console Example