MicroProfile LRA Failure Performance Evaluation

This project is part of the evaluation of a Saga pattern implementation using MicroProfile LRA. Additional sections to the original Saga Pattern Realization with MicroProfile LRA have been included that simulate different failure scenarios given a particular input.

Start the Application

Run ./gradlew clean build
Execute docker-compose up

Requesting trip bookings is now possible. Either use curl commands, the provided TravelApplication.json insomnia file, which includes different trip booking requests, or access the Swagger UI of the different services:

Service	URL to Swagger UI
TravelService	http://localhost:8090/openapi/ui/
LRA Coordinator (included in TravelService)	http://localhost:8090/openapi/ui/
HotelService	http://localhost:8081/openapi/ui/
FlightService	http://localhost:8082/openapi/ui/

To simulate a Saga that fails because no hotel or no flight is available, use one of the following Strings as destination country in the trip booking request:

"Provoke hotel failure"

"Provoke flight failure"

The services also provide a general health endpoint that shows information about the system whether it is up and running. These endpoints can be accessed via:

Service	URL to health endpoint
TravelService	http://localhost:8090/health
HotelService	http://localhost:8081/health
FlightService	http://localhost:8082/health

If you are on Windows or Mac, you sometimes have to replace localhost with the default IP of your docker machine (use docker-machine ip default to get this default IP).

Stop the Application

To stop the application and remove the created containers, execute the following command:

docker-compose down --remove-orphans

Provoke Failure Scenarios

The respective String has to be used as destination country in the trip booking request to provoke a participant failure.

An example for such a request:

TravelRequest

{
    "duration":
    {
        "start":"2021-12-01",
        "end":"2021-12-12"
    },
    "start":
    {
        "country":"Scotland",
        "city":"Stirling"
    },
    "destination":
    {
        "country":"Provoke orchestrator failure while starting trip booking",
        "city":"Bamberg"
    },
    "travellerName": "Orchestrator Start",
    "boardType":"All-inclusive",
    "customerId":"4"
}

1. Saga Participant Failure

Provoke a failure of the FlightService participant before it started to execute a local transaction with the following string as destination country:
```
"Provoke participant failure before receiving task"
```
The HotelService terminates then the docker container of the FlightService while it is executing the bookHotel request. Afterwards, the FlightService has to be restarted manually to investigate what happens as soon as the service is running again. This can be done using one of the following commands:
```
  docker-compose start flightservice

  docker start flightservice_conductorFailurePerf
```
If the container name of the FlightService has been changed in the docker-compose.yml file, the container has to be started using this name with the docker start command. The same applies for the docker-compose start command if the service name of the FlightService has been changed in the docker-compose.yml file.
Provoke a termination failure of the FlightService participant while executing a local transaction of the BookTripSaga with the following string as destination country:
```
  "Provoke participant failure while executing"
```
The FlightService forces then its JVM to terminate itself, after booking a flight but before informing the orchestrator about it, in order to simulate a sudden failure of the system. Afterwards, the FlightService, again, has to be restarted using the same commands as above.
Provoke an exception in the FlightService participant while executing a local transaction of the BookTripSaga with the following string as destination country:
```
  "Provoke exception while executing"
```
The FlightService throws then a RuntimeException while booking a flight to simulate unexpected behaviour of the system. Afterwards, the behaviour of the service can be observed. The easiest way is to have a look at the log of the FlightService during that time. This can be done using the following command: shell docker logs flightservice_conductorFailurePerf --follow

2. Saga Orchestrator Failure

The LRA Coordinator within the TravelService, as well as the TravelService itself are the orchestrator in this example application. Consequently, observing the system's behaviour during orchestrator failures involves failures of this service.

Provoke a failure of the TravelService while a trip booking is being started is not considered, since the TravelService is needed in order to make booking requests.
Provoke a failure of the TravelService while executing a local transaction of the BookTripSaga with the following string as destination country:
```
  "Provoke orchestrator failure while executing"
```
The FlightService terminates then the docker container of the TravelService after booking a flight, but before informing the orchestrator about it. Afterwards, the TravelService has to be restarted manually to investigate what happens as soon as the service is running again. This can be done using one of the following commands:
```
  docker-compose start conductor-server-ui

  docker start conductor-server-ui
```
If the container name of the TravelService has been changed in the docker-compose.yml file, the container has to be started using this name.

3. Breach of Saga Protocol

A participant might send the same message twice to the orchestrator, or even send an old one. Therefore, the scenario of sending an old message to the orchestrator has been added to the implementation in order to evaluate how an implementation using MicroProfile LRA handles this situation.

Provoke the HotelService to send an old message to the LRACoordinator with the following string as destination country:
```
"Provoke sending old message to orchestrator"
```
When the complete endpoint of the HotelService is invoked by the LRACoordinator, the HotelService creates then a new thread that waits for five minutes before it sends the same answer as before to the LRACoordinator again. To achieve this, the HotelService sends the old message, in this case the lraId, to the provided endpoint /{lraID}/close. The service's logs document when it sends the old message.

Code Link

MicroProfile_Implementations/MicroProfile_FailurePerf-Evaluation

Last update: 2022-02-15