> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-troubleshooting/a-missing-event-among-billions-how-we-found-it-on-an-event-mesh/day-2-13-retry-logic-on-the-publisher.md).
# Day 2/13 Retry Logic on the Publisher
##
The application sends the event message to the event broker using a client messaging library, which is built on the top of TCP protocol. Both the client messaging library and the TCP layer have built-in retry logic, which relies on ACK (acknowledge), sometimes NACK (negative acknowledge) and time-out to attempt redeliveries.TCP, which means transmission control protocol, facilitates the reliable transmission of data between devices.
## 1. Retry on the TCP Layer
When sending an event over TCP, the event message is packaged into one or more network packets. The operating system then transmits these packets to the target device in order, utilizing a stateful connection with a sliding window. TCP uses retry mechanism based on the ACK packet and time-out to ensures that all packets are successfully transmitted and received by the target device, as well as network throttling and congestion avoidance. TCP provides a fair amount of reliability and benefits at the networking layer.
According to the TCP/IP protocol, the sender maintains a sliding window buffer that holds all packets that have been sent but not yet acknowledged. Instead of waiting for an acknowledgment after each packet, TCP allows the sender to transmit multiple packets within the window size.
## 2. Retry on the Client Messaging Library Layer
The client messaging library sends an event message to the event broker, and waits for the ACK or NACK from the event broker in asynchronous mode. The sent event is temporarily stored in a memory buffer until the client messaging library receives the ACK or NACK from the event broker (or network issues or time-out waiting for ACK/ NACK). The size of window buffer (windows size) is defined by the application, which determines the maximum number of event messages that can be pending for the ACK or NACK. The application can only send a new event when the window is open and there is free space available in the window buffer. The client messaging library incorporates a mechanism to resend event message in the message of an ACK/ NACK is not received from the broker within a specified period of time (default 2 seconds), often caused by network connectivity issues. If a published event message is not acknowledged by the broker within this time, the library will attempt to resend it. The event broker can de-duplicate the retransmitted event from the client messaging library by means of internal sequencing numbers on the persistent flow.
## 3. Retry on the Application Layer
If the application sends event messages in persistent delivery mode, it is essential for the application to receive an ACK or NACK for every event it sends to the event broker through the client messaging library. The ACK or NACK informs the application whether the event has been successfully received or rejected by the event broker. Rejection might be due to situations like resource limit reached (e.g. queue full), publish ACL violation, or capability mismatch. The application should be programmed to handle these NACK replies, and make the decision to resend or not. NOTE: the API will not automatically resend a NACKed message during due to these failure reasons; only due to network issues or broker failovers. The following diagram shows the possible configuration which causes event loss.
From the application’s perspective, an event message can be sent synchronously or asynchronously. When sending events asynchronously, the application must implement retry logic based on the NACK response from the messaging library layer which is delivered to the publish event handler via a separate thread. Applications sending event messages synchronously, on the other hand, will block waiting for the send result, either returning if successful, or throwing an exception. While synchronous send is simpler to implement retry logic than asynchronous send, its performance can be drastically slower. When JMS 1.1 API is used, however, only blocking synchronous send is supported for persistent messaging.
In either case of asynchronous (streaming) or synchronous (blocking) publishing, the application needs to verify the success of the publish operation; and if it fails, the application must decide what to do with it: republish, do nothing (i.e. “lose” the message), log-and-continue, publish to a different “error” topic, etc.
🚀 Let's Connect Beyond GitBook!
If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:
* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).
***
#### 📬 Stay Ahead of the Curve
Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.
👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/messaging-troubleshooting/a-missing-event-among-billions-how-we-found-it-on-an-event-mesh/day-2-13-retry-logic-on-the-publisher.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
