10:41 a.m.
Properties for each message
---------------------------
Key: JGRP-1250
URL: https://jira.jboss.org/browse/JGRP-1250
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:41 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1250) Quality of service properties per message
[
https://jira.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin.sy...
]
Bela Ban updated JGRP-1250:
---------------------------
Summary: Quality of service properties per message (was: Properties for each
message)
Quality of service properties per message
-----------------------------------------
Key: JGRP-1250
URL: https://jira.jboss.org/browse/JGRP-1250
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1250) Quality of service properties per message
[
https://jira.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1250:
--------------------------------
Added NO_RELIABILITY (bypasses UNICAST, UNICAST2, NAKACK and SMACK) and NO_TOTAL_ORDER
(bypasses SEQUENCER).
This is temporary; a more generic implementation will be tackled in 3.x.
Quality of service properties per message
-----------------------------------------
Key: JGRP-1250
URL: https://jira.jboss.org/browse/JGRP-1250
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1250) Quality of service properties per message
[
https://jira.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin.sy...
]
Bela Ban updated JGRP-1250:
---------------------------
Fix Version/s: 3.0
(was: 2.12)
Quality of service properties per message
-----------------------------------------
Key: JGRP-1250
URL: https://jira.jboss.org/browse/JGRP-1250
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:33 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1250:
--------------------------------
We could club the byte fields flags and transient_flags together into a short, and reserve
only the last 2 elements of the resulting 15 bits for transient flags. That would give us
13 flags instead of the current 7 flags...
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.0
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:35 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1250:
---------------------------
Fix Version/s: 3.1
(was: 3.0)
Moved to 3.1, as this doesn't require any API changes
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:58 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
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
3:57 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1250.
----------------------------
Resolution: Done
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
7:48 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban reopened JGRP-1250:
----------------------------
Change API for setFlag(short) etc into an enum
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
7:50 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1250:
---------------------------
Fix Version/s: 3.0.2
Investigate a backport to 3.0.2
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.0.2, 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
9:10 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1250:
--------------------------------
OK, changed API to use enums Flag and TransientFlag, plus backported to 3.0.2
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.0.2, 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
9:24 a.m.
New subject: [JBoss JIRA] (JGRP-1250) Quality of service properties per message
[
https://issues.jboss.org/browse/JGRP-1250?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1250.
----------------------------
Resolution: Done
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.0.2, 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
4732
days inactive
5120
days old
11 comments
5 participants
participants (5)
-
Bela Ban (Commented) (JIRA) -
Bela Ban (JIRA)
-
Bela Ban (Reopened) (JIRA)
-
Bela Ban (Resolved) (JIRA)
-
Bela Ban (Updated) (JIRA)