3 ms·
You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics": "Method calls are execut
by eliben 4y ago
You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics":
"Method calls are executed with at-most-once semantics. This means that Service Weaver does not automatically retry method calls that fail. However, you can detect and retry failed method calls explicitly using weaver.ErrRetriable. If a method call fails because of a transient system error (e.g., a component replica crashed, the network is partitioned), it returns an error with an embedded weaver.ErrRetriable."
With the following example:
// Retry the cache.Get method call up to five times.
var val string
var err error
for i := 0; i < 5; i++ {
val, err = cache.Get(ctx, "key")
if errors.Is(err, weaver.ErrRetriable) {
// Retriable system error! Retry.
continue
}
break
}
[The docs at https://serviceweaver.dev/docs.html https://serviceweaver.dev/docs.html are fairly comprehensive, kudos to the team!]
- gedw99 4y agoThanks for this as I was also wondering about network partitioning, and all those failure fun and games that distributed systems must handle. This golang package helps to remedy that by providing a bus / messsge queue that can run in process or over the network. So you get rpc without thinking about it and failure is managed by the data plane forwarding the message when the network is healthy again. https://github.com/suborbital/e2core/blob/main/foundation/bus/README.md https://github.com/suborbital/e2core/blob/main/foundation/bu... This however forces all other code using a package like this to adapt to the realities that you’re in an async non blocking world now. A rpc call will give you a response eventually. So the calling func and all parent funcs will just have to wait around when the network is unhealthy?