Thanks for all your input. I'm going to try and implement the appender we need to maintain our current throttling infrastructure. I will send a patch with the changes we need as far as moving items from private to protected and removing the final keyword.
On Sat, Aug 30, 2014 at 2:02 PM, Matt Sicker <[email protected]> wrote: > http://logging.apache.org/log4j/2.x/manual/filters.html#BurstFilter > http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender > > There are several ways to go about implementing what you're asking about > using existing features. You may be able to get what you need by using just > the burst filter and routing appender (which itself may not be required > depending on your usage). > > > On 30 August 2014 09:27, Jeff Shaw <[email protected]> wrote: > > > It sounds like a feature that belongs to any logger. Syslog doesn't need > > to know that a database server is unavailable every nanosecond, either. > > > > Sent from my phone > > > > > On Aug 30, 2014, at 3:19 AM, Remko Popma <[email protected]> > wrote: > > > > > > This sounds like a good feature to have in log4j2. I remember we had an > > issue at work where error logs were emailed automatically, bringing down > > the mail server when the app kept generating the same error. Painful. > > > > > > Sent from my iPhone > > > > > >> On 2014/08/30, at 7:24, Michael Schall <[email protected]> wrote: > > >> > > >> Again, thanks for all the interest in my request. > > >> > > >> I don't have the code in front of me, but I will try and give an > > >> overview of what we did for log4j 1.x. > > >> > > >> We want to send emails for errors happening in production. However for > > >> example, we don't want to send thousands of emails if the network goes > > >> down to a database. If we have an issue that attempts to send more > > >> than X emails in a timeframe, we want to only send 1 email at high > > >> priority and "archive" the rest. If the issue is not resolved we may > > >> send multiple high priority emails until the issue is resolved, but > > >> only a fraction of the emails are actually sent. > > >> > > >> We have a standalone service that does all the throttling logic by > > >> watching a folder for file creations. So the appender I'm talking > > >> about writing doesn't actually send emails. It just does everything > > >> the SmtpAppender does (buffering, evaluating, ...), but writes a file > > >> to a "watch" folder instead of sending messages. The service then > > >> either sends the mail or throttles and sends at high priority. > > >> > > >> So, my thought is that I would extend the SmtpAppender and override > > >> the sendEvents method to write out the contents of the buffer to a > > >> file. This approach has worked great with log4j 1.x. > > >> > > >> Mike > > >> > > >>> On Aug 29, 2014, at 11:28 PM, Ralph Goers < > [email protected]> > > wrote: > > >>> > > >>> This is a fair point. There are some things not in the API that we > > wouldn’t change as they would also break compatibility, such as the > Layout > > or Appender interface, but we aren’t guaranteeing that specific Appender > or > > Layout instances won’t have a new parameter added to them or things like > > that. > > >>> > > >>> Ralph > > >>> > > >>>> On Aug 29, 2014, at 3:22 PM, Remko Popma <[email protected]> > > wrote: > > >>>> > > >>>> I would not object to changing SmtpAppender to make it more > > extendible. > > >>>> > > >>>> Can you tell me more about your use case? SmtpAppender is designed > > this way > > >>>> because we had a specific usage in mind. By understanding your use > > case we > > >>>> might be able to improve the design in a way that benefits not just > > you but > > >>>> other users as well. What do you want to do that you can't do with > the > > >>>> current SmtpAppender? > > >>>> > > >>>> Looks like several changes are required. I am away from my PC and > > can't > > >>>> judge the details now. Could you raise a feature request Jira and > > attach a > > >>>> patch that includes all the changes you'd like to make? That might > > save us > > >>>> some going back and forth. > > >>>> > > >>>> Thanks! > > >>>> Remko > > >>>> > > >>>>> On Friday, August 29, 2014, Michael Schall <[email protected]> > > wrote: > > >>>>> > > >>>>> Thanks for your response Remko. > > >>>>> > > >>>>> Looking into this further, I could duplicate the SmtpAppender code > > as it > > >>>>> really just seems to do plugin work. The bulk of the code is in > the > > >>>>> SmtpManager class which is not marked final. The constructor is > > marked > > >>>>> protected, however it takes a private class (FactoryData). I would > > also > > >>>>> like to override the sendEvents method, but then I run into issues > > because > > >>>>> the buffer is private. > > >>>>> > > >>>>> Do these changes seem like an issue? > > >>>>> > > >>>>> Mike > > >>>>> > > >>>>> > > >>>>> On Fri, Aug 29, 2014 at 4:51 PM, Remko Popma < > [email protected] > > >>>>> <javascript:;>> wrote: > > >>>>> > > >>>>>> Looks like this class was made final in January 2013. The commit > > message > > >>>>>> mentions checkstyle errors. > > >>>>>> What change are you proposing? Would just removing the final > > keyword from > > >>>>>> the class definition be enough to fulfill your needs? > > >>>>>> > > >>>>>> It may be good to raise this as a feature request in Jira. > > >>>>>> If you need more changes than just making the class non-final, > > please > > >>>>>> attach a patch with the changes you have in mind. > > >>>>>> > > >>>>>> > > >>>>>> On Sat, Aug 30, 2014 at 4:07 AM, Michael Schall < > > [email protected] > > >>>>> <javascript:;>> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> I'm upgrading an application to use Log4j2. With our existing > > >>>>>>> implementation we have created a new appender which extends the > > >>>>>>> SMTPAppender. I see the SMTPAppender is a final class now which > > >>>>> prevents > > >>>>>>> me from extending it. I was wondering what the reason for this > > is? Do > > >>>>>> we > > >>>>>>> really need to re-implement the the entire SMTPAppender > > (properties, > > >>>>>>> buffering, ...) to extend the appender? > > >>>>>>> > > >>>>>>> Thanks for your time. > > >>>>>>> > > >>>>>>> Mike > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Matt Sicker <[email protected]> >
