[
https://issues.apache.org/jira/browse/LOG4J2-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388301#comment-17388301
]
Matt Sicker commented on LOG4J2-3066:
-------------------------------------
I'm not sure if it comes out of the box, but the zguide itself has example
design patterns for implementing this. See for example:
*
https://zguide.zeromq.org/docs/chapter4/#Disconnected-Reliability-Titanic-Pattern
(for reliable client-side delivery)
*
https://zguide.zeromq.org/docs/chapter4/#High-Availability-Pair-Binary-Star-Pattern
(for server-side high availability)
* https://zguide.zeromq.org/docs/chapter5/#Reliable-Pub-Sub-Clone-Pattern
(pub/sub variant)
As mentioned in the guide, there are even some message queues that use ZeroMQ
as an implementation detail.
> Improve Socket Appender error handling
> --------------------------------------
>
> Key: LOG4J2-3066
> URL: https://issues.apache.org/jira/browse/LOG4J2-3066
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
> Affects Versions: 2.14.1
> Reporter: Ralph Goers
> Priority: Major
>
> When the SocketAppender is unable to connect to any hosts it should start
> logging to a file on disk similar to the way the FlumeAppender works. Once
> the connection is re-established all queued events should be removed from the
> file and sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
