Indian Train Anti-Pattern

Last time, I talked about the Marsupilami Pattern, where we introduce queues to transport data between application layers.

Now you’ve been using these queues for some time, conveying all sorts of data, and you realize that they are getting quite crowded, like those Indian Trains we see sometimes on TV. So crowded that people are standing on the roof. You might think that this is not a problem. Those are internal queues, so you can handle all this data internally, adding some more memory. Data might lag a little, but you are not doing “real time”, some seconds do not hurt.

But what if the Indian Train enters into the UI Thread? What if your user clicks on the menu bar, and the mouse events ends up at the end of the train. Would he want to use program where menus take several seconds to appear?

Or what if the Indian Train gets sent on the network? It might impact all the other applications sharing the network with yours, and they might not be happy playing the role of those sacred cows watching the Indian Train pass.

But what is to be done? Your Display class, for instance, is quite straightforward:

public class Display {

    public void show(Data data) {

        SwingUtilities.invokeLater(() -> table.addRow(data));
    }

}

Data is received, data is displayed. So simple. But sometimes, simplicity is too naive. One possible solution is to use the Indiana Jones Pattern. Wait for it!