[
https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1868:
---------------------------
Fix Version/s: 3.6
There are a lot of other things that are wrong if a system has that many retransmissions.
SeqnoList is optimized for size and if an XMIT-REQ grows over 65K then the first prio
should not be to look into how to fix this, but how to prevent this. I suspect this is the
old story again where thread pools are getting clogged by Infinispan...
The workaround is to place {{FRAG}} just above the transport.
Size of XMIT_REQ is not limited
-------------------------------
Key: JGRP-1868
URL:
https://issues.jboss.org/browse/JGRP-1868
Project: JGroups
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Radim Vansa
Assignee: Bela Ban
Fix For: 3.6
When UNICAST3 sends XMIT_REQ, it serializes SeqnoList as payload without any limits upon
its size. If there are too many missing messages, the XMIT_REQ grows over
TP.max_bundle_size and cannot be sent at all.
{code}
JGRP000029: edg-perf03-10774: failed sending message to edg-perf01-63702 (64072 bytes):
java.lang.Exception: message size (64072) is greater than max bundling size (64000). Set
the fragmentation/bundle size in FRAG and TP correctly, headers: UNICAST3: XMIT_REQ,
seqno=0, UDP: [channel_name=default]
{code}
It's also undesirable to resend thousands of messages, as the receiver likely cannot
process them all at once and only few of them will be actually processed. Therefore only X
oldest ones (in order to cleanup the tables) should be resent.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)