Godzilla Anti-Pattern

Last time, I presented the Santa Claus Pattern, where you would send several messages wrapped up in the same packet to lower payload and increase performance.
However, if you create your packets without discrimination, sooner or later, you’ll meet Godzilla, the packet of monstrous size. Sending huge packets on your intranet can have quite a bad effects on all the other applications of your ecosystem. Some communication frameworks even forbid packets that are too big. For instance, I recently met Godzilla in a system using Weblogic, where maximum packet size is set to 50MB by default. Even more recently, I met a similar case with OmniOrb.

On a User Interface, big packets will make your windows seem to freeze. Although the processor is working at full speed to handle all your messages, the repaint will happen only after the whole packet is handled, and the user will not understand why nothing happens on the screen.

The way to handle Godzilla is of course to set a limit to the size of your packets. If we take the code from Santa Claus, a simple modification will help you avoid Godzilla:

private void sendData() {
  if (!queue.isEmpty()) {
    List<Message> packet = new ArrayList<>();
    queue.drainTo(packet, MAX_PACKET_SIZE);
    sendPacket(packet);
  }
}

As a way to fight both Godzilla and its opposite, next time I’ll show the Opera Lift Pattern.