MulticastDetector crashes my network

[yt.nash]

Hello all!

At this moment, I am developing a solution using JBoss Remoting (2.2.1GA) and I have detected a ugly problem with MulticastDetector.

If you try to launch SimpleDetectorClient (included as JBoss Remoting sample of detection multicast), I have a problem. You can see it installing a nextwork monitor and... This execution sends to the network 32 UDP packets per second!!! After time, network gets down (no connection, no Internet).

However, if you execute SimpleDetectorServer (in the same branch), the packet rate is 1 per second (acceptable in a server-side environment).

I have tried to play with heartbeat time delay and default time delay and I don't have positive results. After change it, the frequency of packets is the same (client-side and server-side).

Can someone help me?

Thanks!

Santiago Ameller.

[yt.nash]

I have developed a CustomMulticastDetector in order to solve my problem.

Debugging JBoss Remoting code, I have seen that MulticastDetector has implemented a listener behavior without time delay [ while(running) { ... } // running = true ].

My CustomMulticastDetector introduces this missing delay (using Timer and TimerTask) and it doesn't run! My client detects when some server has been launched, but not when has got down!

Is fast-multicast necessary for correct operation?

Thanks again!

[ron_sigal]

I've created a JIRA issue to look into this problem: http://jira.jboss.com/jira/browse/JBREM-991 "Investigate MulticastDetector message flood".

As I noted, there is some odd looking behavior in MulticastDetector.listen():

 else
 {
 // for now, assume anything *not* of type Detection
 // is a prompt to send out detection msg
 heartbeat();
 }

As long as you're playing with the MulticastDetector, you might want to comment out this clause and see what happens.

[ron_sigal]

Hi Santiago,

I think I see what is happening. As I commented in 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.

If you want to test my fix, it's just the insertion of two lines in org.jboss.remoting.detection.multicast.MulticastDetector.heartbeat()

 if(socket != null)
 {
 Detection msg = createDetection();
 if (msg == null) // <== inserted
 return; // <== inserted
 ...

-Ron

[yt.nash]

Thank you for your response Ron!

In order to solve this problem I fixed the flooding commenting the else clause inside org.jboss.remoting.detection.multicast.MulticastDetector.listen(). I undestand that your way to fixing the bug is better than my solution!

Thanks again!

[ron_sigal]

I fixed the flooding

Great. I'm glad you solved the problem and moved on. :-)

Thanks for telling me about the problem.