TCP/Beats transport should be queuing about python-logstash-async HOT 4 CLOSED

This is exactly what this handler aims to do.
On network errors (like when no listeners running) the events are queued and re-sent later as long as the events could be delivered successfully. Currently there is no backoff logic but it could be implemented.

Did you experience loss of events due to transmission problems?

from python-logstash-async.

problem occured to me when I run this handler while there is no destination listening (immediately)

from python-logstash-async.

here is my sample logging script: https://gist.github.com/jesusch/6283670bbd294a0a16525c01a0253bd3
and here is the console output of running it: https://gist.github.com/jesusch/a7a86083c6ca2cdf0699d7978b172a67

from python-logstash-async.

This is as expected:
the handler tries to send the events and if it fails, the events are queued in the SQLite database.
Every QUEUED_EVENTS_FLUSH_INTERVAL seconds or every QUEUED_EVENTS_FLUSH_COUNT events (https://github.com/eht16/python-logstash-async/blob/master/logstash_async/constants.py#L19) resending is tried (the new events as well as the events queued in the database).

You should find the events in the database and they will be re-sent once you restart your test application.

I guess there is just a misunderstanding in the behavior:
the handler will not keep the application running until the events could be delivered successfully. This is out of scope of a logging handler. However the handler performs a last transmission attempt on exit (i.e. if the logging subsystem is shutdown).

from python-logstash-async.