Bug 673225 - Need to clarify meaning of "rec hdr and tail"
Summary: Need to clarify meaning of "rec hdr and tail"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Messaging_Programming_Reference
Version: 1.3
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: 2.0
: ---
Assignee: Alison Young
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-27 18:50 UTC by mdarretta
Modified: 2012-09-21 12:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-24 02:54:54 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description mdarretta 2011-01-27 18:50:22 UTC
In section 6.4.3, examples 6.1 and 6.2, all the size parameters are well defined except for "rec hdr and tail". I would make sense to define this parameter just like the others to remove ambiguity.

Comment 1 Lana Brindley 2011-02-03 00:02:17 UTC
Please provide further information for documentation.

LKB

Comment 2 mdarretta 2011-02-07 22:32:04 UTC
I don't know what these are? I am simply trying to go through the documentation and came across this portion in the examples, and there was no explanation.

Comment 3 Lana Brindley 2011-02-07 23:41:42 UTC
Gordon,

Are you able to help out with source documentation?

LKB

Comment 4 Gordon Sim 2011-02-08 10:19:41 UTC
The 'rec hdr and tail' is the combination of 'enqueue header size' and 'enqueue  record tail' defined in the text preceding the example. I'd suggest to change the line in the example from:

An average enqueue record will consume 150 (msg) + 75 (msg header) + 44 (rec hdr and tail) = 269 bytes.

to:

An average enqueue record will consume 32 (enqueue header size) + 150 (msg) + 75 (msg header) + 12 (enqueue record tail) = 269 bytes. 

Even better would perhaps be to change 'enqueue header size' to 'enqueue record header' for consistency, both in the example and in the preceding text.

Any comments, Kim?

Comment 5 Kim van der Riet 2011-03-22 11:11:33 UTC
This seems fine to me.

The journal uses records to store data. If the record contains data (such as enqueue records), then the record consists of a record header and a record tail, with the data sandwiched between these two. Any space remaining between the end of the tail and the next 128-byte boundary remains unused; the next journal record will start on this boundary.

The user data supplied to the journal from the broker comes in two parts, a message header and the message data itself. The journal, however, treats both of these as a single block of opaque binary data.

128-byte                                     128 byte
boundary                                     boundary
   |                                            |
---+-----+------------------------+-----+-------+---
   | rec |           user         | rec | extra |    
   | hdr |           data         | tail| space |    
---+-----+------------------------+-----+-------+--- 
         |                        |
        /                          \
       /                            \
      |                              |
      +-----+------------------------+
      | msg |         message        |    Broker's view of
      | hdr |          data          |    the user data
      +-----+------------------------+

For the size calculations, the journal's record header and record tail are fixed in size, being 32 bytes and 12 bytes respectively (total: 44 bytes). The broker's user data size is variable, and examples must state exactly how big the message header and message data portion of the user data will be (in the example above, 75 bytes for the header and 150 bytes for the message data).


Note You need to log in before you can comment on or make changes to this bug.