Fault-Tolerance Evaluation - Baseline
Required Implementation Changes
- Logger class
- Create SuDuelKuServerBean.ftEvalInit(String repStyle, int numClients, int interReqTime, int replySize, int teamNum)
- Create new methods in SuDuelKuServerBean (our point of entrance) that duplicate all existing methods but include a reply message of definable size. The methods will simply call the previously existing methods and return their results along with the definable size message.
- Modify our "scripted" client to accept the inter-request time as a parameter.
- Add 4 probes to the "scripted" client to log:
- Time request was sent.
- Time reply was received.
- Method invoked.
- Add 4 probes to SuDuelKuServerBean (our single point of entry) to log:
- Time request was received.
- Time reply was sent.
- Method invoked.
- Client ID sent with request (for mapping to hostname).
Required Scripts
- Database reset/clear.
- Client behavior.
- Master - calls database reset/clear, restarts jboss, and launches clients according to all permutations of variables(numClients, interReqTime, replySize).
Design for Fault-Tolerance Evaluation
We will re-run the same scenarios, scripts, and variable configurations as done in the fault free case, but they will be run while injecting faults. We will record when faults are injected into the system and when fail-over to a back-up completes. We will compare latency in the fault free case to the fault recovery case. These numbers can be used to help determine real-time scheduling.
Gotchas:
- Local clock for Fault-Injector and Recovery Manager will be different then local clock for client and server.
- Adding logging (probes) to our application will impact performance.
- Collecting data from our system while running scripts is artificial and does not capture "true" system behavior.