Fix busy-waiting loops

Description

Busy-waiting, or spinning, is a technique where a process repeatedly checks to see if a condition is true, such as whether keyboard input or a lock is available. While it might seem like a good idea, it has several significant drawbacks:

1. CPU Usage: Busy-waiting can consume a lot of CPU time. While a process is busy-waiting, it keeps the CPU busy. This can prevent other processes from running and can lead to high CPU usage, especially if the condition being checked doesn't become true for a long time.
2. Performance: Busy-waiting can lead to performance issues. If a process is busy-waiting, it's not doing any useful work. This can slow down the overall performance of your application.
3. Responsiveness: Busy-waiting can make your application less responsive. If a process is busy-waiting, it might not be able to respond to user input or other events in a timely manner.
4. Power Consumption: Busy-waiting can lead to increased power consumption, especially on battery-powered devices. This is because the CPU is kept busy and is not allowed to enter a low-power state.

Instead of busy-waiting, it's generally better to use some form of event-driven programming or blocking. This allows your process to sleep until the condition it's waiting for becomes true, which can save CPU time, improve performance, and make your application more responsive.

Busy-waiting loops are at least in these locations:

1. Server Session / App.java
2. Twin / BallThread.java
3. Log Aggregation / LogAggregator.java
4. Commander / Retry.java
5. Retry / Retry.java
6. Retry / RetryExponentialBackoff.java
7. Queue-Based Load Leveling / ServiceExecutor.java

Acceptance Criteria

• Busy-waiting loops refactored
• README.md of the affected patterns revised as needed

Inspect the busy-waiting loops in Server Session/App.java, Twin/BallThread.java, Log Aggregation/LogAggregator.java, Commander/Retry.java, Retry/Retry.java, Retry/RetryExponentialBackoff.java, and Queue-Based Load Leveling/ServiceExecutor.java. Review each affected pattern's README.md and determine how the loop should wait without spinning. Done means the listed loops are refactored and the affected README files are revised as needed.