[jboss-jira] [JBoss JIRA] (JGRP-1250) Quality of service properties per message

[Bela Ban (Commented) (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646021#comment-12646021 ] 

Bela Ban commented on JGRP-1250:
--------------------------------

I decided to change Message.flags from a byte to short. The reason is that it is impossible to introduce variable bitsets, in other words to add a random number of bits to a message:
- A byte array would introduce a ref plus the usual object overhead plus the length
- Same for a bit set
- A header would work, but setting and querying flags should be *fast*, so the 'flags' field needs to be part of a message
- Users wanting to add arbitrary information usually need more than bits, and this can be done with headers
- Message.flags is usually only used by JGroups (internally), so adding another 8 flags (going from 7 to 15 bits in a short) should be sufficient for the foreseeable future.
- Adding a byte (diff between short and byte) to org.jgroups.Message may not even increase the memory footprint of a message, as padding (aligning objects on word boundaries) will likely allocate more memory for an object than the sum of its fields require anyway
                
> Quality of service properties per message
> -----------------------------------------
>
>                 Key: JGRP-1250
>                 URL: https://issues.jboss.org/browse/JGRP-1250
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.1
>
>
> JGroups already has the ability to bypass certain protocols, e.g. NO_FC set in a message bypasses any flow control layer. 
> It would be nice to do this for other protocols, too, e.g. SEQUENCER, but this needs to be done in a generic fashion.
> What should be done is to use *properties*, e.g. +reliable-mcast, -frag, +flowcontrol, -bundling etc. Based on these flags, each protocol decides whether to handle (or not) a message. The properties should not take up *any* space in a message if not set.
> This can probably be generalized, ie. by annotating a protocol with the props it provides, e.g. @Reliable @ReliableUnicast UNICAST, and by having code which matches the flags in a message and decides whether or not to process the message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira