Open daviddawson opened 7 years ago
It was very usefull to generate at each invoke some transactionalId, then put it to header + put to redis cache for example. and if remote consumer (ie http client) was timeouted. transactionalId removed from cache. When remote rpc will consumed, check transactionalId existence in redis. if it not exist - future work doesnt needed and we must throw an exception for recursive rollback upsteaming consumers. i think it could good for some of kind distributed transactions.
Thanks @zotona
We're sending events over the muon event api (here -> https://github.com/muoncore/stack-event). We could back that using redis, but there's no implementation of that right now.
I think what we'll do is to have a service that emits an event as the request, then wait for a "fail" or "success" event using one of the subscribers as at https://github.com/muoncore/newton/blob/master/java/newton-sample/src/main/java/io/muoncore/newton/todo/TaskViewStore.java
Rpc using events is implemented by emitting an event, then waiting until a response event is generated.
This is suitable for when the request/ response actually forms useful data/ state in the system rather than just being simple interaction.
This could be implemented in newton as a specialisation of BaseSubscriber. By listening to the streams that the events will come back on, and adding/ removing listener predicates as needed before emitting the request event, effective RPC can be overlaid onto stream processing.