[ https://jira.jboss.org/browse/JGRP-1256?page=com.atlassian.jira.plugin.sy... ] ronald yang updated JGRP-1256: ------------------------------ Attachment: mping.xml -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JGRP-1256?page=com.atlassian.jira.plugin.sy... ] ronald yang commented on JGRP-1256: ----------------------------------- it's pretty clear to me that my change won't enforce a hard limit on the xmit buf size, but I feel it's better to bail out early when a known invariant is about to be violated (highest_delivered is not supposed to exceed highest_received?). Without this check then we have to wait for the long value to wrap around which will take a while. Maybe the right thing to do, for trimming the xmit buf, is to count up starting from low? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JGRP-1256?page=com.atlassian.jira.plugin.sy... ] Bela Ban commented on JGRP-1256: -------------------------------- Hmm, maybe I should get rid of max_xmit_buf_size altogether ! Discarding messages to keep the buffer bounded might lead to endless retransmission loops in other members when they didn't receive a message M, but the sender already trashed M because of max_xmit_buf_size. Sending back an I-don't-have-M message won't cut it either, as this would require extensive changes... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JGRP-1256?page=com.atlassian.jira.plugin.sy... ] Bela Ban edited comment on JGRP-1256 at 12/1/10 8:04 AM: --------------------------------------------------------- Yes, I agree: iterating from low to highest_received and removing all messages from xmit_table until xmit_table.size() <= max_xmit_buf_size is correct. However, I'm seriously thinking about removing max_xmit_buf_size altogether (see above)... long current=low; while(max_xmit_buf_size > 0 && xmit_table.size() > max_xmit_buf_size && current <= highest_received) { Message tmp=xmit_table.remove(current); retransmitter.remove(current); if(current > highest_delivered) { highest_delivered=next_to_remove; if(retval == null) retval=new LinkedList<Message>(); if(tmp != null) retval.add(tmp); } current++; } was (Author: bela(a)jboss.com): Yes, I agree: iterating from low to highest_received and removing all messages from xmit_table until xmit_table.size() <= max_xmit_buf_size is correct. However, I'm seriously thinking about removing max_xmit_buf_size altogether (see above)... long current=low; while(max_xmit_buf_size > 0 && xmit_table.size() > max_xmit_buf_size && current <= highest_received) { xmit_table.remove(current); retransmitter.remove(current); if(current > highest_delivered) highest_delivered=next_to_remove; current++; } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira