Saga feature does not work in docker-compose deployment

[futurexv2016]

Hello Chris & all,

I followed the step in README to deploy all services to test Saga pattern by docker-compose in local PC

1. ./gradlew assemble
2. ./gradlew :composeUp
3. I create order by using : http://localhost:8082/swagger-ui.html#/order-controller/createUsingPOST

But output is order is always with state = APPROVAL_PENDING. There is no interactions with Consume service, Kitchen service... It seems that order service cannot send to Kafka or Kafka cannot deliver message to other services.

4. To debug, I connect to mysql and see that table: saga_instance_participants/ftgo_order_service(db) has no participants

5. Also, no ticket created in Kitchen DB:

6. I did not see any log appeared in other service other than order service when sending create order request meaning that other service cannot invoked by events issued in order service.

Can you help to point out which steps I was missing? Thanks

[asn25]

Hi, this happens on revise order operation? What about CreateOrderSaga, test on create order operation, it should produce Saga content and participants.

What for ReviseOrderSaga, it might be connected with issues:

• Attempt to revise a cancelled order breaks the system - and all subsequently created orders are broken https://github.com/microservices-patterns/ftgo-application/issues/70
  • ReviseOrder does not work correctly https://github.com/microservices-patterns/ftgo-application/issues/38

Also I'll add some comment to your observation: "But output is order is always with state = APPROVAL_PENDING. " This happens also in the case of CreateOrderSaga even when Saga works OK, because the system uses "Return before processing end" pattern.

So when you use CreateOrder operation, you will receive APPROVAL_PENDING response at once, but in parallel there will be a Saga start (asynchronously) and in some reasonable time (500-2000ms) the order becomes APPROVED (Saga does its work). So the one should not be fooled by immediate JSON response "APPROVAL_PENDING" in that case, this is not an error yet.

But if you tested revise order operation, it might be buggy and might be connected with issues mentioned above.

[futurexv2016]

Hi,

Thanks for your reply,

It is CreateOrderSaga (you can see the POST in Postman picture). The thing is state = APPROVAL_PENDING forever meaning that Saga does not work, no reply from other services - no log, no ticket created in ticket table in Kitchen database. You can see no records in table saga_instance_participants in order DB too. It is strange

[cer]

The most likely explanation is that something is not correct with Kafka messaging.

What's the output of docker-compose ps after some time has passed - the containers that were initially healthy might become unhealthy.

Also, the most interesting tables are:

• saga_instance (in the order service)
• message
• received_messages

What's in each service's tables?

(please add links to gists if the output is too long)

[asn25]

In clause 3 in your screen I see that you do POST to URL: .../orders/6/revise

So you do revise, I guess. Not create.

If you got such a broken state of the system after revise operation, then all future sagas will not work - you need to fully restart the system (under docker) as described in issue #70. Do full restart and do create operation (POST to /orders) - the Saga should work.

What for revise operation, it should be investigated further and fixed (somewhen).

[futurexv2016]

Hi all,

I've redeployed and it worked without touching anything.

@cer Thanks for your response, could you help answer my wonder:

1. Is this possible to use another message broker other than Kafka? I use K8S in GCP and it use google-cloud-PubSub ?
2. Do we have any solution to solve the scenario for Restful synchronous communication rather than event-driven programming ? ex: ServiceA --> ServiceB --> ServiceC by REST. However, compensation methods can be triggered by event as Eventuate Tram supports now

@asn25 Yeah, my bad, thanks for your reply.

[cer]

1. Is this possible to use another message broker other than Kafka? I use K8S in GCP and it use google-cloud-PubSub ?

See https://github.com/eventuate-tram/eventuate-tram-core/issues/122

[cer]

I've redeployed and it worked without touching anything.

Glad it works now, There must have been a glitch the first time, and one of the services had not started properly.

[cer]

2. Do we have any solution to solve the scenario for Restful synchronous communication rather than event-driven programming ?

This scenario is not currently supported by Tram.