Queues, the Software Panacea

There’s a fun story here about how two Microsoft support guys back in the late 80s worked out how to crash the entire support team’s phone system.

It was right about then everyone’s phones died. Anyone who was talking to a customer was cut off, and our phones didn’t work at all for about 20 minutes.

The underlying problem was too many logging statements being written to a database, which got overloaded, crashed, and then crashed the phone system. My immediate thought: they needed a queueing system for logging statements.

It’s quick to put something in a queue. The system can take items from the front of the queue at its leisure. It will catch up with backlogs when people are at home sleeping.

Poker Copilot is full of queues. Queues, queues, queues. It seems almost every difficult technical problem I face in Poker Copilot can be solved with a queue.

When hand history files are updated, Poker Copilot places them in a special queue where the most recently updated files go to the front. A busy little worker thread takes a file off that queue, parses the file and places each parsed hand into another queue. When you move poker tables around, causing the HUD to move, there’s a queue. Feature usage tracking is placed in a queue. Twice. First on your computer and then on the feature tracking server. All database queries in Poker Copilot are placed in a queue.

Java version 5 and upwards makes queues easy. It has several types of thread-safe queues with high concurrency built in.