[
https://jira.jboss.org/jira/browse/JGRP-947?page=com.atlassian.jira.plugi...
]
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