[
https://jira.jboss.org/jira/browse/JBREM-991?page=com.atlassian.jira.plug...
]
Ron Sigal commented on JBREM-991:
---------------------------------
It seems that the problem is a combination of
1) the fact that listen() calls heartbeat() upon receiving something other than a
Detection, and
2) the fact that when heartbeat() creates a null Detection (due to the fact that there
are no servers running in the JVM), it sends an empty packet.
So heartbeat() sends a null Detection, listen() receives it and calls heartbeat(), which
sends out a Detection, etc. The problem is that, even though the timing of heartbeat()
running in the Heartbeat TimerTask is regulated, listen() is not - it responds immediately
upon reading something from the multicast socket, and the response can include a call to
heartbeat.
MulticastDetector.heartbeat() has been changed so that if it creates a null Detection, it
just returns instead of sending it.
There are no particular unit tests. Will watch hudson for multicast detection related
failures.
Investigate MulticastDetector message flood
-------------------------------------------
Key: JBREM-991
URL:
https://jira.jboss.org/jira/browse/JBREM-991
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.4.0.SP1
A use has reported that org.jboss.remoting.detection.multicast.MulticastDetector is
flooding the network with messages. The problem might lie MulticastDetector.listen():
else
{
// for now, assume anything *not* of type Detection
// is a prompt to send out detection msg
heartbeat();
}
--
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