Wow, Paul thought to himself, "signing up for a new account takes a little while, huh? He was new on the job and clicking through to get a handle on the application he'd be maintaining. He opened the code to see what the signup button was actually doing behind the scenes.

The design was kind of strange; all HTTP requests were routed through Actions. Most Actions inherited from other Actions – for instance, LoginAction and SignupAction inherited from DelayableAction, which inherited from ActionBase.

DelayableAction had a public abstract method called "getProcessingDelay()," as well as a public method called "delay()."

public void delay() {
    try {
        Thread.sleep(getProcessingDelay());
    } catch (InterruptedException ignored) {} }

Each of the Actions that inherited from DelayableAction implemented getProcessingDelay(), reading a delay from a config file for actions to be completed. LoginAction had a 1500 ms delay, while SignupAction had a 5000 ms delay.

But Why?

Paul and team had a few brainstorming sessions as to why DelayableAction was created in the first place. They didn't arrive at any definitive conclusion, and since they couldn't find any code comments explaining it, nor any issues in their issue tracking system making any reference to it. They figured it had to be one of the following:

  1. Perhaps to aid in debugging, since separate threads writing to the log might have some statements written from one thread interlaced with staements from other threads.
  2. He'd just learned to write web applications that way.
  3. Boredom.
  4. The application was running too fast and he'd wanted to give the users the perception that something important was happening.

Whatever the reason for the feature, it wasn't necessary. Removing the feature didn't break anything, so now it runs a lot faster.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!