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

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990655#comment-12990655 ] 

Radim Vansa commented on JGRP-1868:
-----------------------------------

Yes, it is the old story with all threads stuck at UFC. I am getting sick&tired of the stacktraces. At least now I have more info: I dump JGroups debug info (managed attributes etc.) and threadpool sizes every 10 seconds, so I can see how this happened. Not that I would have any clues yet.

> 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) 
>    Affects Versions: 3.4.4, 3.5
>            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)