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
{{ message }}
Repository navigation
Commit 4d79669
Browse filesBrowse the repository at this point in the historyBrowse files
refactor: drop timeout registry and merge the demo services
TimeoutRegistry was configuration scaffolding rather than part of the
pattern, so App now builds its TimeoutPolicy values directly.
ProductCatalogService and RecommendationService only differed in name,
latency and payload, so they collapse into a single parameterised
DownstreamService and App's two near-identical helpers into one call
helper.
README, PlantUML diagram and tests follow; the sample output block is
taken from a real run of the demo.
`TimeoutExecutor` runs the call on a worker thread and waits for at most the configured duration. On a timeout it cancels the worker with an interrupt, logs the event, counts it in `TimeoutMetrics`, and returns the fallback. A failure raised by the service, or a call the pool refuses to accept, is not a timeout and is rethrown as `ServiceCallException`.
118
93
@@ -160,64 +135,52 @@ public class TimeoutExecutor implements AutoCloseable {
160
135
}
161
136
```
162
137
163
-
4.**Make the slow service cooperate with cancellation**
138
+
3.**Make the service cooperate with cancellation**
164
139
165
-
The simulated `RecommendationService` sleeps interruptibly, so the interrupt sent by the executor actually stops the work instead of leaving it running in the background.
140
+
The simulated `DownstreamService` sleeps interruptibly, so the interrupt sent by the executor actually stops the work instead of leaving it running in the background. Its name, latency and payload are constructor arguments, so the same class plays both the fast catalog and the slow recommendation engine.
`App`registers a 500 ms limit for the catalog and a 100 ms limit for recommendations. Each call lives in a small helper that pairs the policy with the call and its fallback; `main` runs both. The catalog answers in time; the recommendation engine needs 400 ms, so the customer sees popular items instead and the timeout counter shows one event.
157
+
`App`gives the catalog a 500 ms limit and recommendations a 100 ms one, then runs both calls through a small helper that pairs the policy with the call and its fallback. The catalog answers in time; the recommendation engine needs 400 ms, so the customer sees popular items instead and the timeout counter shows one event.
0 commit comments