How is that any different than creating a new manager as your recovery logic? Remember, the reason for doing this is a) the managers live across reconfigurations while appenders don’t and b) the appenders should be fairly simple - the managers deal with all these kinds of complexities. For example, there are 3 variations of the Flume Appender but there is only one FlumeAppender class. There are 3 Flume Managers to handle each implementation and the appender simply picks one based on how it was configured.
Ralph > On Jul 10, 2017, at 11:15 AM, Gary Gregory <[email protected]> wrote: > > Another idea, possibly whacky, is for an Appender to have two managers. > When one goes bad, you initialize the 2nd based on the same factory data, > then close the 1st one. The 2nd becomes current, rinse, repeat. Not sure > how this fits in w manager cacheing. > > Gary > > On Jun 28, 2017 13:37, "Matt Sicker" <[email protected]> wrote: > >> 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]> >>
