[jboss-jira] [JBoss JIRA] Commented: (JGRP-947) Messages that are bundled but are over max_bundle_size are silently dropped on the floor.

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-947:
-------------------------------

NAKACK actually doesn't use OOB anymore, so retransmitted messages *are* bundled. This means that every retransmission causes this stack trace.

Propagating the exception all the way up to the caller is not a good idea IMO, because the caller might re-send the buffer and then we even compound the issue.

I guess we need to catch this misconfiguration issue at stack start time, ie. throw an exception if FRAG2.frag_size > TP.max_bundle_size (if bundling is enabled)

> Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
> -----------------------------------------------------------------------------------------
>
>                 Key: JGRP-947
>                 URL: https://jira.jboss.org/jira/browse/JGRP-947
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: JGroups version 2.7.0
>            Reporter: Hunter Kelly
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> in TP.java, at line 1562, an error is thrown if a packet is too big.  However, this exception is caught in TP.java at line 913.  It is logged, but in my opinion this error should be propagated all the way up the call stack.
> This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
> This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
> IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
> It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira