[jboss-jira] [JBoss JIRA] (JGRP-1868) Size of XMIT_REQ is not limited

Bela Ban (JIRA) issues at jboss.org
Wed Aug 6 04:48:29 EDT 2014


     [ https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)


More information about the jboss-jira mailing list