For testing networking systems, load simulators are useful: send a bunch of realistic looking traffic and see what happens as you increase the amount of sent traffic. These sorts of simulators often rely on being heavily multithreaded, since one computer can, if pushed, generate a lot of network traffic.

Thus, when Jonas inherited a heavily multithreaded system for simulating load, that wasn't a surprise. The surprise was that the developer responsible for it didn't really understand threading in Java. Probably in other languages too, but in this case, Java was what they were using.

        public void startTraffic()
        {
            Configuration.instance.inititiateStatistics();
            Statistics.instance.addStatisticListener(gui);
           
            if (t != null)
            {
                if (t.isAlive())
                {
                    t.destroy();
                }
            }
           
            t = new Thread(this);
            t.start();
        }

Look, this is not a good way to manage threads in Java. I don't know if I'd call it a WTF, but it's very much a "baby's first threading" approach. There are better abstractions around threads that would avoid the need to manage thread instances directly. I certainly don't love situations where a Runnable also manages its own thread instance.

This is almost certainly a race condition, but I don't know if this function is called from multiple threads (but I suspect it might be).

But what's more interesting is where this code gets called. You see, starting a thread could trigger an exception, so you need to handle that:

        public void run()
        {
            while (true)
            {
                try
                {
                    loaderMain.startTraffic();
                    break;
                }
                catch (Exception e)
                {
                    System.out.println("Exception in main loader thread!");
                    e.printStackTrace();
                }
            }
        }

Inside of an infinite loop, we try to start traffic. If we succeed, we break out of the loop. If we fail, well, we try and try again and again and again and again and again and again…

Jonas writes:

Since I'm the only one that dares to wade through the opaque mess of code that somehow, against all odds, manages to work most of the time, I get to fix it whenever it presents strange behavior.

I suspect it's going to present much more strange behavior in the future.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.