[
https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1710:
---------------------------
Workaround Description: Place *FRAG* just above the transport. FRAG (in contrary to
FRAG2) uses {{Message.size()}} to determine whether a message needs to be fragmented, and
therefore takes headers into account, too.
Workaround: Workaround Exists
Messages get too large due to big headers (in large clusters)
-------------------------------------------------------------
Key: JGRP-1710
URL:
https://issues.jboss.org/browse/JGRP-1710
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.4
In some cases, messages get bigger than the max bundling size because of large headers:
{panel}
ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] |
(org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to
172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size
(70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in
FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]:
view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{panel}
In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the
digest in the header. With 1479 members (as shown the the example above), this increases
the message size beyond the max bundling size.
Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira