logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schall <mike.sch...@gmail.com>
Subject Re: Extending Appenders
Date Tue, 02 Sep 2014 16:08:45 GMT
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 <boards@gmail.com> 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 <jeff@bitgladiator.com> 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 <remko.popma@gmail.com>
> 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 <mike.schall@gmail.com> 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 <
> ralph.goers@dslextreme.com>
> > 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 <remko.popma@gmail.com>
> > 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 <mike.schall@gmail.com>
> > 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 <
> remko.popma@gmail.com
> > >>>>> <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 <
> > mike.schall@gmail.com
> > >>>>> <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: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
> --
> Matt Sicker <boards@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message