[
https://issues.jboss.org/browse/JGRP-1259?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1259:
--------------------------------
Hmm, View cannot esaily be compressed. Sending only the ViewId and a list of indices (one
for each member) would only work if everybody had the ViewId available. This would work
for V1={A,B,C,D} --> V2={A,B,C} (D leaving), but not for V1={A,B,C} --> V2={A,B,C,D}
(D joining)... unless we serialized D explicitly here... This needs more thought. A
similar effect could be had by canonicalizing Addresses into IDs, but for different
reasons this was pushed into 3.x
Reduce size of large headers: place data into message itself
------------------------------------------------------------
Key: JGRP-1259
URL:
https://issues.jboss.org/browse/JGRP-1259
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
When we send a view around, we essentially create an empty Message and attach a
GmsHeader.VIEW with the new view.
If the view consists of 200 members, the view header will be very big and the message is
still empty (null buffer).
The issue here is that FRAG2 only fragments the message's buffer (this is faster),
and so a huge header might add so much to the size of a serialized message that the
transport (UDP) won't be able to send it !
SOLUTION: still use the header (e.g. GmsHeader.VIEW), but place potentially large
payloads into the message. This will allow FRAG2 to fragment the message very efficiently.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira