<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Deployment on OpAMP Commander</title><link>https://minuk.dev/opampcommander/docs/deployment/</link><description>Recent content in Deployment on OpAMP Commander</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://minuk.dev/opampcommander/docs/deployment/index.xml" rel="self" type="application/rss+xml"/><item><title>Kafka outages</title><link>https://minuk.dev/opampcommander/docs/deployment/kafka-degradation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://minuk.dev/opampcommander/docs/deployment/kafka-degradation/</guid><description>&lt;p&gt;Kafka events are best-effort notifications of state already saved in the database.&#10;An API success confirms persistence, not broker delivery or an agent acknowledgement.&#10;The same-node event path dispatches directly to local connections without Kafka.&lt;/p&gt;&#10;&lt;p&gt;For remote agents, notifications normally prompt an immediate push. If a notification&#10;or cache invalidation is lost, subsequent OpAMP heartbeats reload persisted state&#10;once the agent cache expires (30s by default). Cache reads do not extend that TTL.&#10;Recovery therefore depends on the database remaining available and the agent sending&#10;another message; it does not require Kafka to reconnect. Later updates may supersede&#10;older desired state. This is state convergence, not an ordered replay of every command&#10;or an exactly-once execution guarantee. Previously stored restart requests can now&#10;be offered after a reload if the reported agent start time precedes the request;&#10;a newer reported start time suppresses the command.&lt;/p&gt;</description></item></channel></rss>