You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Sources/DistributedActors/DistributedActors.docc/Clustering.md
+41-5Lines changed: 41 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -98,7 +98,7 @@ Similarly, you can implement the [ServiceDiscovery](https://github.com/apple/swi
98
98
and this will then enable the cluster to locate nodes to contact and join automatically. It also benefits all other uses of service discovery in such new environment,
99
99
so we encourage publishing your implementations if you're able to!
100
100
101
-
## Cluster events
101
+
## Cluster Events
102
102
103
103
Cluster events are events emitted by the cluster as changes happen to the lifecycle of members of the cluster.
104
104
@@ -273,19 +273,55 @@ distributed actor Boss: LifecycleWatch {
273
273
274
274
Remote calls are at the heart of what makes distributed actors actually distributed.
275
275
276
-
A call made on a remote distributed actor reference, will cross network boundaries, and therefore may way due to
276
+
A call made on a remote distributed actor reference will cross network boundaries, and therefore may fail due to
277
277
network issues, message loss, serialization errors, or other reasons such as the recipient node crashing as it
278
278
processes the message. Even replies to remote calls could sometimes fail being delivered, so you might need to
279
279
design your distributed actors with idempotency (the resilience of a method being called more than once, e.g. due to a retry) in mind.
280
280
281
281
By default, to avoid "hanging" a remote caller forever on a suspended remote call as the recipient node fails to reply to it,
282
-
for example because it (or the network itself), are currently unresponsive, remote calls have a default timeout configured,
283
-
and if no reply is received within this duration, the call will fail with a ``RemoteCallError``.
282
+
for example because it (or the network itself), is currently unresponsive, remote calls have a default timeout configured.
283
+
If no reply is received within this duration, the call will fail with a ``RemoteCallError.timedOut``.
284
284
285
285
You can configure the default timeout used by the cluster system during its initialization:
286
286
287
287
```swift
288
288
ClusterSystem() { settings in
289
-
settings.
289
+
settings.remoteCall.defaultTimeout= .seconds(3)
290
+
}
291
+
```
292
+
293
+
You can override the default timeout for a specific remote call:
294
+
295
+
```swift
296
+
tryawait RemoteCall.with(timeout: .seconds(5)) {
297
+
tryawait worker.work()
298
+
}
299
+
```
300
+
301
+
### Remote call errors
302
+
303
+
By default, if a remote call results in an error that is ``Codable``, the error is returned as-is. Non-``Codable`` errors are
304
+
converted to ``GenericRemoteCallError``.
305
+
306
+
You may restrict which ``Codable`` errors get sent back to the caller through configuration:
307
+
308
+
```swift
309
+
ClusterSystem() { settings in
310
+
// By default, all ``Codable`` errors are allowed.
311
+
settings.remoteCall.codableErrorAllowance= .all
312
+
}
313
+
```
314
+
315
+
```swift
316
+
ClusterSystem() { settings in
317
+
// Only specific types are allowed. All others are returned as ``GenericRemoteCallError``.
0 commit comments