# Persistent Queue details **URL:** \ **Category:** Logstash\ **Created:** [August 6, 2018, 9:32am UTC](https://discuss.elastic.co/t/persistent-queue-details/143133 "2018-08-06T09:32:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![JST](https://avatars.discourse-cdn.com/v4/letter/j/edb3f5/32.png) [@JST](https://discuss.elastic.co/u/JST)\ **Post date:** [August 6, 2018, 9:32am UTC](https://discuss.elastic.co/t/persistent-queue-details/143133/1 "2018-08-06T09:32:51Z")
All, I have the following setup: [tcp, http, file, udp] ---\> logstash ---\> [custom output plugin] And a few questions on persistent queues. 1. As per [the limitions](https://www.elastic.co/guide/en/logstash/current/persistent-queues.html#persistent-queues-limitations) do the tcp and udp inputs enter the persistent queue or bypass it completely? Does "not protected against data loss" just mean that the data source won't receive an ACK and thus doesn't know if it should "release" the event if logstash has a failure? 2. For output, does logstash only remove from the persistent queue when it receives an ACK from the data destination? 3. Is there any guidance on how to develop an output plugin to be compatible with Persistent queues? I assume there must be some feedback from the output plugin to indicate that the data destination has successfully received the data, therefore allowing logstash to pop from the queue? 4. Are output plugins such as udp incompatible with persistent queues due to the lack of guaranteed delivery / no ACK? Thanks very much, Jason ---
**Author:** ![yaauie](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yaauie/32/23363_2.png) [@yaauie](https://discuss.elastic.co/u/yaauie)\ **Post date:** [August 8, 2018, 12:49am UTC](https://discuss.elastic.co/t/persistent-queue-details/143133/2 "2018-08-08T00:49:53Z")
Very astute questions! I'll attempt to answer in-line: > [@JST](#): > > - As per [the limitions](https://www.elastic.co/guide/en/logstash/current/persistent-queues.html#persistent-queues-limitations) do the tcp and udp inputs enter the persistent queue or bypass it completely? Does "not protected against data loss" just mean that the data source won't receive an ACK and thus doesn't know if it should "release" the event if logstash has a failure? When the PQ is enabled on a pipeline, _all inputs_ put items into the PQ (whether or not they can provide at-least-once delivery semantics). When a pipeline consistently is processing events slower than its inputs are putting them into the queue, the queue can fill up. When the queue reaches the configured maximum capacity, attempts by inputs to put things into the queue will block until there is sufficient available capacity. Unfortunately, with inputs like TCP and UDP, the input blocking simply means that it is no longer _reading_ the bytes from the underlying socket; the OS will continue to accept input (for TCP, this _may_ be ACK'd at the protocol level). These buffers, bytes that have been received by the OS but have not been _read_ by the TCP/UDP input, are at risk. The sender has handed off responsibility, but Logstash hasn't yet actually _accepted_ responsibility. > [@JST](#): > > - For output, does logstash only remove from the persistent queue when it receives an ACK from the data destination? Each Output Plugin is implemented differently, but in general, outputs retry their batches of input until success. If the Dead Letter Queue is enabled, failures can be flushed to a separate disk-based queue for later analysis and replay. > [@JST](#): > > - Is there any guidance on how to develop an output plugin to be compatible with Persistent queues? I assume there must be some feedback from the output plugin to indicate that the data destination has successfully received the data, therefore allowing logstash to pop from the queue? Mostly: just keep trying; don't return until the plugin has either succeeded or has handed off the events to the DLQ. > [@JST](#): > > - Are output plugins such as udp incompatible with persistent queues due to the lack of guaranteed delivery / no ACK? There is still _some_ benefit, since the PQ provides a buffer that is resilient across process restarts. This buffer is often big enough to handle momentary spikes in traffic, accepting the UDP packets off of the more fragile buffers and getting them onto disk. * * * If you're just looking into PQ's, make sure you start with at least [Logstash 6.3.0](https://www.elastic.co/guide/en/logstash/current/logstash-6-3-0.html) -- we had several bugs get fixed in that release. ---
**Author:** ![JST](https://avatars.discourse-cdn.com/v4/letter/j/edb3f5/32.png) [@JST](https://discuss.elastic.co/u/JST)\ **Post date:** [August 8, 2018, 12:26pm UTC](https://discuss.elastic.co/t/persistent-queue-details/143133/3 "2018-08-08T12:26:50Z")
> Each Output Plugin is implemented differently, but in general, outputs retry their batches of input until success. If the Dead Letter Queue is enabled, failures can be flushed to a separate disk-based queue for later analysis and replay. Ok, so when the data is being processed by my Output plugin it has already been popped from the PQ? If the output plugin is unable to deliver it, or Logstash was to reboot/crash at this point then the data will be lost? (Assuming the Output plugin doens't have some kind of buffering mechanism for failed sends) Thanks, Jason ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 5, 2018, 12:27pm UTC](https://discuss.elastic.co/t/persistent-queue-details/143133/4 "2018-09-05T12:27:03Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.