The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
90 lines
6.2 KiB
Plaintext
90 lines
6.2 KiB
Plaintext
# 이 데코레이터가 자기에게 매긴 계약
|
|
FailOpenNotificationProvider.java:7 /**
|
|
FailOpenNotificationProvider.java:8 * Fail-open decorator: a provider failure is logged (no payload/PII) and swallowed so a
|
|
FailOpenNotificationProvider.java:9 * notification — a side-effect — never fails the core use case. Applied centrally by
|
|
FailOpenNotificationProvider.java:10 * NotificationConfig.
|
|
FailOpenNotificationProvider.java:11 */
|
|
|
|
# 실패 경로 : catch 안에서 실패 로그를 부른다
|
|
FailOpenNotificationProvider.java:35 @Override
|
|
FailOpenNotificationProvider.java:36 public void send(Notification notification) {
|
|
FailOpenNotificationProvider.java:37 try {
|
|
FailOpenNotificationProvider.java:38 delegate.send(notification);
|
|
FailOpenNotificationProvider.java:39 dependencyLogger.logSuccess(delegate.providerId(), DEPENDENCY_TYPE, "send");
|
|
FailOpenNotificationProvider.java:40 } catch (Exception ex) {
|
|
FailOpenNotificationProvider.java:41 // fail-open: observe (no payload/PII), do not fail the core use case.
|
|
FailOpenNotificationProvider.java:42 dependencyLogger.logFailure(delegate.providerId(), DEPENDENCY_TYPE, "send", ex);
|
|
FailOpenNotificationProvider.java:43 }
|
|
FailOpenNotificationProvider.java:44 }
|
|
FailOpenNotificationProvider.java:45 }
|
|
|
|
# 메시징 쪽의 같은 자리 : catch 안도 observeQuietly 를 거친다
|
|
OutboundMessagePublisher.java:26 @Override
|
|
OutboundMessagePublisher.java:27 public void publish(OutboundMessage message) {
|
|
OutboundMessagePublisher.java:28 // The send and the observation are separate steps because they used to share a try block: a
|
|
OutboundMessagePublisher.java:29 // logger that threw after a successful send was caught by the same catch and reported as a
|
|
OutboundMessagePublisher.java:30 // publish failure. The broker had accepted the message; the only thing that failed was the
|
|
OutboundMessagePublisher.java:31 // record of it, and the two must not be confusable.
|
|
OutboundMessagePublisher.java:32 boolean sent = false;
|
|
OutboundMessagePublisher.java:33 try {
|
|
OutboundMessagePublisher.java:34 broker.send(message);
|
|
OutboundMessagePublisher.java:35 sent = true;
|
|
OutboundMessagePublisher.java:36 } catch (Exception ex) {
|
|
OutboundMessagePublisher.java:37 // fail-open: observe with correlationId, delegate durability to outbox/retry,
|
|
OutboundMessagePublisher.java:38 // do NOT propagate — the core use case must still succeed.
|
|
OutboundMessagePublisher.java:39 observeQuietly(
|
|
OutboundMessagePublisher.java:40 () -> dependencyLogger.logFailure(broker.brokerId(), DEPENDENCY_TYPE, "publish", ex));
|
|
OutboundMessagePublisher.java:41 }
|
|
OutboundMessagePublisher.java:42 if (sent) {
|
|
OutboundMessagePublisher.java:43 observeQuietly(
|
|
OutboundMessagePublisher.java:44 () -> dependencyLogger.logSuccess(broker.brokerId(), DEPENDENCY_TYPE, "publish"));
|
|
OutboundMessagePublisher.java:45 }
|
|
OutboundMessagePublisher.java:46 }
|
|
OutboundMessagePublisher.java:48 /**
|
|
OutboundMessagePublisher.java:49 * Runs an observation, absorbing whatever it throws.
|
|
OutboundMessagePublisher.java:50 *
|
|
OutboundMessagePublisher.java:51 * <p>Diagnostics are non-authoritative. An appender that is out of disk must not change what the
|
|
OutboundMessagePublisher.java:52 * caller believes about the broker.
|
|
OutboundMessagePublisher.java:53 */
|
|
OutboundMessagePublisher.java:54 private static void observeQuietly(Runnable observation) {
|
|
OutboundMessagePublisher.java:55 try {
|
|
OutboundMessagePublisher.java:56 observation.run();
|
|
OutboundMessagePublisher.java:57 } catch (RuntimeException ignored) {
|
|
OutboundMessagePublisher.java:58 // Nothing to report it to: the reporter is what failed.
|
|
OutboundMessagePublisher.java:59 }
|
|
OutboundMessagePublisher.java:60 }
|
|
|
|
# 그 데코레이터를 부르는 팬아웃 루프
|
|
RoutingNotifier.java:112 @Override
|
|
RoutingNotifier.java:113 public void notify(Channel channel, String route, Notification notification) {
|
|
RoutingNotifier.java:114 List<String> providerIds = resolveRoute(channel, route);
|
|
RoutingNotifier.java:115 Map<String, FailOpenNotificationProvider> channelRegistry =
|
|
RoutingNotifier.java:116 registry.getOrDefault(channel, Map.of());
|
|
RoutingNotifier.java:117 // FailOpenNotificationProvider.send declares no throws — no try/catch needed.
|
|
RoutingNotifier.java:118 // Individual provider failures are observed (logged) inside the decorator
|
|
RoutingNotifier.java:119 // and never propagated, so one failure does not block remaining fan-out sends.
|
|
RoutingNotifier.java:120 for (String providerId : providerIds) {
|
|
RoutingNotifier.java:121 channelRegistry.get(providerId).send(notification);
|
|
RoutingNotifier.java:122 }
|
|
RoutingNotifier.java:123 }
|
|
|
|
# 위임 제공자가 던지는 경로에 로거 예외를 겹쳤을 때
|
|
probe:26 if (n.equals("warn")) {
|
|
probe:29 throw new IllegalStateException("the appender is out of disk");
|
|
probe:56 throw new IllegalStateException("provider is down");
|
|
probe:65 new FailOpenNotificationProvider(failing(), new FailOpenDependencyLogger(logger(warnThrows)));
|
|
probe:70 p.send(null);
|
|
probe:71 } catch (RuntimeException ex) {
|
|
위임 제공자가 던지는 경로 (fail-open 이 삼켜야 하는 경우)
|
|
실패 로거가 정상일 때 debug 0 · warn 1 · 호출자에게 나간 예외 없음
|
|
그 예외가 제공자 예외를 달고 있는가 : cause=없음 · suppressed=0
|
|
실패 로거도 던질 때 debug 0 · warn 1 · 호출자에게 나간 예외 IllegalStateException: the appender is out of disk
|
|
그 예외가 제공자 예외를 달고 있는가 : cause=없음 · suppressed=0
|
|
|
|
# 그 경로를 고정하는 시험이 있는가
|
|
알림 모듈에서 Proxy.newProxyInstance 로 로거를 만드는 자리 : 0 개
|
|
메시징 모듈에서 같은 자리 : 1 개
|
|
이 데코레이터를 조립하는 시험이 던지게 만드는 대상 :
|
|
NotificationAdapterTest.java:79 throw new RuntimeException("provider-failure");
|
|
RoutingNotifierTest.java:130 throw new RuntimeException("provider-failure");
|