Eventuate Tram Failure Performance Evaluation

This project is part of the evaluation of a Saga pattern implementation using the Eventuate Tram and Eventuate Tram Sagas framework. Additional sections to the original Saga Pattern Realization with Eventuate Tram 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/swagger-ui.html
HotelService	http://localhost:8081/swagger-ui.html
FlightService	http://localhost:8082/swagger-ui.html

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"

Additionally, the Zipkin UI can be accessed to trace performed calls: http://localhost:9411/zipkin/

The services also provide a health and an info endpoint that show some information about the system like that the DB is up and running. These endpoints can be accessed via:

Service	URL to health endpoint	URL to info endpoint
TravelService	http://localhost:8090/api/travel/monitor/health	http://localhost:8090/api/travel/monitor/info
HotelService	http://localhost:8081/api/hotels/monitor/health	http://localhost:8081/api/hotels/monitor/info
FlightService	http://localhost:8082/api/flights/monitor/health	http://localhost:8082/api/flights/monitor/info

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_eventuateFailurePerf
```
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.
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:
```
docker logs flightservice_eventuateFailurePerf --follow
```

2. Saga Orchestrator Failure

The TravelService plays the orchestrator role in this example application. However, it also needs Eventuate's CDC service to publish messages to the participants and vice versa. Consequently, observing the system's behaviour during orchestrator failures involves failures of the TravelService as well as the CDC service.

Provoke a failure of the CDC service while a trip booking is being started with the following string as destination country:
```
"Provoke orchestrator failure while starting trip booking"
```
The TravelService terminates then the docker container of the CDC Service while it is executing the bookTrip request but before starting the BookTripSaga. Afterwards, the CDC Service 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 cdcservice

docker start cdcservice
```
If the container name of the CDC service has been changed in the docker-compose.yml file, the container has to be started using this name.
Provoke a failure of the CDC service while executing a local transaction of the BookTripSaga with the following string as destination country:
```
"Provoke CDC failure while executing"
```
The FlightService terminates then the docker container of the CDC Service after booking a flight, but before informing the orchestrator about it. Afterwards, the CDC service, again, has to be restarted using the same commands as above.
Provoke a failure of the orchestrator, which means 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 the same commands as before, but with travelservice as the service name, respectively travelservice_eventuateFailurePerf as the container name.

3. Breach of Saga Protocol

A participant might send the same message twice to the orchestrator, or even send an old one. To handle such situations, EventuateTram offers a pluggable duplicate message detction mechanism¹. For this the service's ApplicationContext has to define a DuplicateMessageDetector bean and the following dependency has to be added to the build.gradle file:

compile "io.eventuate.tram.core:eventuate-tram-spring-consumer-jdbc:$eventuateTramVersion"

Additionally, either auto–configuration has to be enabled or @Import TramConsumerJdbcAutoConfiguration needs to be added. If this DuplicateMesageDetector is being used, managing transactions in the respective message handler classes needs to be deactivated, for exmaple remove using the @Transactional annotation.

Code Link

EventuateTram_Implementations/EventuateTram_FailurePerf-Evaluation

https://eventuate.io/docs/manual/eventuate-tram/latest/getting-started-eventuate-tram.html#getting-started, last accessed 2022-02-15 ↩

Last update: 2022-02-15