diff options
| author | Paul Buetow <paul@buetow.org> | 2025-06-21 15:54:07 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2025-06-21 15:54:07 +0300 |
| commit | d3b697218773eaa5a3dd368705184726dbc0fa38 (patch) | |
| tree | e466fb78829c957f70e88ab92651896b49120856 /RAFT_TESTING.md | |
| parent | dedec9b18bafa2bcfdb05429f717f95f2236d811 (diff) | |
Implement headless testing framework for DS-Sim protocol simulations
- Created HeadlessSimulationRunner that loads and runs simulations without GUI
- Implemented LogCapture to intercept and store all simulation logs
- Added ProtocolVerifier for flexible pattern-based log verification
- Created test runners: standard, with logs, and clean (filters GUI errors)
- Implemented tests for all non-Raft protocols
- Added DummySimulatorFrame to satisfy GUI dependencies during loading
- Created CleanHeadlessRunner that filters GUI-related errors from output
- Updated run-tests.sh script with quiet mode option
- Documented the framework architecture and usage
The framework successfully runs protocol tests and verifies behavior through
log analysis. GUI errors occur internally due to tight coupling in DS-Sim
but are filtered in quiet mode for clean output.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Diffstat (limited to 'RAFT_TESTING.md')
| -rw-r--r-- | RAFT_TESTING.md | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/RAFT_TESTING.md b/RAFT_TESTING.md new file mode 100644 index 0000000..29a0fba --- /dev/null +++ b/RAFT_TESTING.md @@ -0,0 +1,68 @@ +# Raft Simulation Testing Guide + +## What We Fixed + +The Raft simulation wasn't working because of a fundamental design issue with how protocols are activated: + +1. **Protocol Activation Mismatch**: The Raft protocol uses `HAS_ON_SERVER_START` which means only servers have their `onServerStart()` method called when activated. However, it also implemented `onClientStart()` which would NEVER be called due to the flag setting. + +2. **Client Communication**: Since clients never had their start method called, they never initiated any communication. We fixed this by having clients react to server heartbeats instead. + +## Changes Made + +1. Modified `VSRaftProtocol.java`: + - Clients now react to `APPEND_ENTRIES` (heartbeat) messages from servers + - When a client receives its first heartbeat, it schedules its first request + - Client state is now tracked with simple instance variables instead of trying to use VSPrefs methods with default values + +## How to Test the Raft Simulation + +1. **Build the project**: + ```bash + mvn clean package + ``` + +2. **Create/Update the simulation**: + ```bash + java -cp target/ds-sim-1.0.1-SNAPSHOT.jar examples.RaftSimulationBuilder + ``` + +3. **Run the simulator GUI**: + ```bash + java -jar target/ds-sim-1.0.1-SNAPSHOT.jar + ``` + +4. **Load and run the simulation**: + - Click File → Open + - Navigate to `saved-simulations/raft-consensus.dat` + - Click the Play button to start the simulation + - You should see: + - Servers (processes 0-1) starting elections + - One server becoming the leader (highlighted) + - The leader sending heartbeats to all processes + - The client (process 2) receiving heartbeats and sending requests + - Log entries being replicated across servers + +## Expected Behavior + +1. **Initial State**: All servers start as FOLLOWERS +2. **Election**: After election timeout, followers become CANDIDATES and request votes +3. **Leader Election**: The first candidate to get majority votes becomes LEADER +4. **Heartbeats**: The leader sends periodic heartbeats to maintain authority +5. **Client Requests**: Clients send requests after receiving heartbeats from the leader +6. **Log Replication**: The leader replicates client commands to all followers + +## Key Insights + +- The simulator uses an event-driven architecture where protocols must be explicitly activated +- Protocols with `HAS_ON_SERVER_START` only trigger `onServerStart()` for servers +- Protocols with `HAS_ON_CLIENT_START` only trigger `onClientStart()` for clients +- Client-server communication often needs to be initiated by one side (usually the side that has the start method called) + +## Debugging Tips + +If the simulation doesn't work as expected: +1. Check the console output for any error messages +2. Verify that all 3 processes are created (0-1 as servers, 2 as client) +3. Ensure the protocol activations are scheduled at the right times +4. Look for the election timeout messages and leader elections in the logs
\ No newline at end of file |
