This topic makes me think some sort of CircuitBreakerAppender may be useful as an analogue to FailoverAppender. Instead of permanently failing over to the backup appenders, this appender would eventually switch back to the primary appender when it's safely back up. Supporting a full open/half open/closed type circuit breaker would also be handy, and there's some sample implementation code that can be lifted from commons.
On 26 June 2017 at 00:04, Ralph Goers <[email protected]> wrote: > Managers are not designed to be shutdown and restarted. If you are causing > your manager to come and go for the JMS support then I don’t think you > implemented it correctly. If you look at the tcp socket manager it has a > reconnector inside of it to handle retrying the connection. JMS should work > the same way. In a way, the Rolling appenders do the same thing. Whenever a > rollover occurs they start writing to a new file. This is handled by the > Manager. > > Appenders that are recoverable should successfully start. The managers > should be created but be in a state where they throw exceptions until they > can recover. The appenders should not really have much logic in them and > delegate most of the work to the managers. > > Ralph > > > On Jun 25, 2017, at 8:22 PM, Gary Gregory <[email protected]> > wrote: > > > > Hi All, > > > > I am thinking about how to best solve cases like > > https://issues.apache.org/jira/browse/LOG4J2-1955 > > > > In a nutshell: Log4j starts but some external resource is not available > > (like a JMS broker, a database server, and so on) > > > > Right now, you're out of luck. You other appenders will keep on happily > > logging but your JMS or JDBC appender will never log to their final > > destinations. Even, if, a second (or an hour) after the app is up, the > > external resource becomes available. > > > > A separate use case is what happens when the external resources goes down > > and back up after the app and Log4j have started. The appender usually > > looses its connection to that external resource and events are no logger > > sent to their final repositories. > > > > I just updated the JMS appender to handle the later use case. In brief, > the > > appender detects that its manager has gone stale and recreates one. > (Please > > have a look, a code review is welcome.) > > > > But when I think about the JMS broker not being up when the appender is > > created, then that's a different story. We'd need to allow for the > appender > > to be created with a null manager and then handle that later, when > append() > > is called. > > > > Today, that's a bit of a pain to do because the AbstractManager factory > > method throws a IllegalStateException, so you need to catch that, which > is > > a bit ugly. Not going through the AbstractManager is possible but then > you > > loose the caching it does. > > > > But stepping back I am wondering if we should not let Log4j itself try to > > create appenders at a later time if they were not successfully created on > > start up? > > > > I'm not sure which way to go here. On the one hand, each appender knows > its > > stuff the best especially when it comes to its external resources. OTOH, > > having each appender get more complicated is not great. But making the > > Log4j core itself more complex might not be right either since each > > appender knows its stuff the best. > > > > Thoughts? > > > > I might go all the way with a JMS specific solution and see how that > feels. > > > > Gary > > > -- Matt Sicker <[email protected]>
