Fixes formatting in a table cell in `logstash-monitoring-overview.html`.
A `+` which was required by AsciiDoc was leaking into the output when
the doc is built with Asciidoctor.
* Create running-logstash-windows.asciidoc
Initial commit for #4005
* Update running-logstash-windows
1. Added section to validate JVM pre-requisites and shell sections for nssm, task scheduler, and PowerShell
2. Updated options to run Logstash on Windows, update section headers
3. Clarified JVM pre-requisites and included example to add environmental variables using SETX
4. Added example Logstash configuration, added steps for running Logstash manually with PowerShell
5. Removed `WIP` from the PowerShell section; updated the example to include output to Elasticsearch; Added notes for running Logstash as a service with NSSM
6. Removed `WIP` from the NSSM section; Added notes for running Logstash as a Scheduled Task; Added notes to stopping Logstash for each section; Removed `WIP` from the Scheduled Task section; Removed `WIP` from the page header
7. Updated initial section; moved the running manually section as the first configuration; added notes to the NSSM and Schedule Task sections.
8. Push headings down one level
9. Clarify this document contains examples for running Logstash on Windows. Updated which NSSM file should be extracted for use.
10. Updated formatting for the example Logstash configuration
11. Update formatting for the command examples
12. Update the instructions in the Task Scheduler section
13. Update the instructions in the run Logstash manually section, the NSSM section, and update formatting
14. Update formatting
15. Add note regarding support for running multiple pipelines
16. Clarify use of command line options. Re-state what is mentioned in the `Running Logstash from the Command Line` doc that: "Specifying command line options is useful when you are testing Logstash. However, in a production environment, we recommend that you use [logstash-settings-file] to control Logstash execution."
17. Clarify steps to accessing the Windows Environmental Variables window (i.e., link to Microsoft docs).
18. Remove unnecessary plus signs
19. Updated source types for examples, updated documents for specific Logstash versions with `{logstash_version}`
* Update running-logstash-command-line
1. Add note for running Logstash on Windows with `bin\logstash.bat`
2. Update formatting for running Logstash from the Windows command line
Fixes#10946
It just blocks and doesn't handle the concurrency situation. One can think of the network of connected pipelines as a DAG (We explicitly ask users not to create cycles in our docs). In fact there are two different correct answers to the pipeline shutdown and reload problem.
When reloading pipelines we should assume the user understands whatever changes they're making to the topology. If a downstream pipeline is to be removed, we can assume that's intentional. We don't lose any data from upstream pipelines since those block until that downstream pipeline is restored. To accomplish this none of the `PipelineBus` methods block by default.
When shutting down Logstash we must: 1.) not lose in-flight data, and 2.) not deadlock. The only way to do both is to shutdown the pipelines in order. All state changes happen simultaneously on all piping via multithreading. As a result we don't need to implement a Topological sort or other algorithm to order dependencies, we simply issue a shutdown to all pipelines, and have ones that are dependent block waiting for upstream pipelines.
This patch also correctly handles the case where multiple signals cause pipeline actions to be created simultaneously. If we see two concurrent creates or stops, one of those actions becomes a noop.
Currently the Logstash plugin API has lifecycle methods for starting and stopping, but not reloading. We need to call a different method when a `pipeline` input is stopped due to a pipeline reload vs an agent shutdown. Ideally, we would enrich our plugin API. In the interest of expedience here, however, I added a flag to the `PipelineBus` that changes the shutdown mode of `pipeline` inputs, to be either blocking or non-blocking. It is switched to blocking if a shutdown is triggered.
Fixes#9650
