# Logstash to Logstash via TCP is slow/delayed/waiting for something **URL:** \ **Category:** Logstash\ **Created:** [March 21, 2019, 11:33am UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299 "2019-03-21T11:33:58Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![cawoodm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cawoodm/32/14083_2.png) [@cawoodm](https://discuss.elastic.co/u/cawoodm)\ **Post date:** [March 21, 2019, 11:33am UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/1 "2019-03-21T11:33:58Z")
We process logfiles with filebeat into logstash (CONF1). If the log entry is marked as an error, we clone it and send it to another instance of logstash (CONF2) via the tcp output plugin. The problem is that while we see the message go out (CODE1) the 2nd instance does not show the message on it's output (CODE2) UNTIL we shutdown logstash2. Then we see our message (see below). Why the "delay"? What is logstash waiting for in order to flush? CONF1: ```auto output { if [@metadata][index] == "errors" { # CODE1 stdout {codec => rubydebug { metadata => true } } # Reprocess errors with Logstash tcp { host => "ecom-repository01" port => "5062" } } } ``` CONF2: ```auto input { tcp { port => 5062 codec => json add_field => { system => "dev" } } } filter {} output { # CODE2 stdout {codec => rubydebug { metadata => true } } } ``` ![image](https://us1.discourse-cdn.com/elastic/original/3X/3/e/3e79493c2c24086fefea349a070849484e521170.png) ---
**Author:** ![cawoodm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cawoodm/32/14083_2.png) [@cawoodm](https://discuss.elastic.co/u/cawoodm)\ **Post date:** [March 22, 2019, 1:12pm UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/2 "2019-03-22T13:12:02Z")
I suspect this is a bug. The DEBUG log is showing me that's it's switching me over to the `json_lines` codec even though I specified the `json` codec. I suspect it's waiting for a newline which never comes. Can anyone confirm this bug? I worked around it by switching from TCP to HTTP input/output plugins. ---
**Author:** ![cawoodm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cawoodm/32/14083_2.png) [@cawoodm](https://discuss.elastic.co/u/cawoodm)\ **Post date:** [March 28, 2019, 6:57am UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/3 "2019-03-28T06:57:08Z")
> ---
**Author:** ![guyboertje](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guyboertje/32/31592_2.png) [@guyboertje](https://discuss.elastic.co/u/guyboertje)\ **Post date:** [March 28, 2019, 10:44am UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/4 "2019-03-28T10:44:22Z")
I saw that you created the issue in the LS repo as well as switching to the http input output pair. I am not sure of the history behind the implicit json\_lines substitution in place of the json codec for inputs. It has been this way for many years. As a matter of interest, did you try the json\_lines codec in the tcp output (the default is json and the switch does not occur for outputs)? ---
**Author:** ![cawoodm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cawoodm/32/14083_2.png) [@cawoodm](https://discuss.elastic.co/u/cawoodm)\ **Post date:** [March 28, 2019, 11:49am UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/5 "2019-03-28T11:49:44Z")
Indeed, if I use the json\_lines codec on both ends it works. Thanks! However, I think I'm gonna stick by my guns and say it's defective as is: many users of LS are gonna try json (because it's a thing) and not json\_lines and conclude that it doesn't work because LS is "ignoring" that the output codec is json. At least if "json\_lines" is the de facto default output codec for tcp it should be the default input. ---
**Author:** ![guyboertje](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/guyboertje/32/31592_2.png) [@guyboertje](https://discuss.elastic.co/u/guyboertje)\ **Post date:** [March 28, 2019, 12:35pm UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/6 "2019-03-28T12:35:30Z")
I understand and yes it is a quirk. I asked to try the json\_lines codec in the tcp output for future readers. However, it is still [our recommendation](https://www.elastic.co/guide/en/logstash/current/ls-to-ls.html) at present to use the `lumberjack output -> beats input` for LS to LS communications because the beats input understands the lumberjack protocol. The lumberjack protocol, at the time of writing, is Logstash specific and IIRC can handle back-pressure better. The quirk is hard to undo as many users will have running Logstash instances that secretly rely on the substitution. The substitution is done by Logstash plugin support code and not in any individual plugin. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 25, 2019, 12:35pm UTC](https://discuss.elastic.co/t/logstash-to-logstash-via-tcp-is-slow-delayed-waiting-for-something/173299/7 "2019-04-25T12:35:37Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.