[jboss-jira] [JBoss JIRA] Commented: (JGRP-528) NAKACK: spurious retransmission requests

[Bela Ban (JIRA)]

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

Bela Ban commented on JGRP-528:
-------------------------------

You should rather post to one of the mailing lists...

There are many things that can cause a CPU to go to 100% utilization... without stack traces we won't know the cause. This issue will not cause 100% utliization.

> NAKACK: spurious retransmission requests 
> -----------------------------------------
>
>                 Key: JGRP-528
>                 URL: https://jira.jboss.org/jira/browse/JGRP-528
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.6
>
>
> Every now and then, spurious retransmission requests are received:
> NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)]
> It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message.
> This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads).
> Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR !

-- 
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