Sounds like what you need is a ByteBurstFilter. This may be generally useful, so we could look at adding this to core. What action do you want to take if the threshold is succeeded? Drop all events from that point?
Sent from my iPhone > On 2016/03/18, at 5:39, Christian <[email protected]> wrote: > > Hi all, > > sorry for the late response and thanks for your responses! > > I don't want to do some statistical stuff, so unfortunately this information > doesn't suit my needs :( > > As Gary said it would be nice for my purpose if I had a listener that's > called right before the log will be written. Maybe with the whole byte-array > or only some information like the byte-size. > > I want to do some stuff inside my application like the BurstFilter - but per > written bytes and not per amounts of events. So I want to do some precautions > when X bytes in Y seconds were written. > In the past we had issues that some loops went crazy and logged the same > messages thousand times per second until our disk was full and the > application was unsuable. And because we only know how many bytes our disk is > able to store and not how many events it is able to store, we couldn't use > the BurstFilter... :( > > The managers aren't final, but it's also very hard to create a new sub class > of a manager, because some factories are private and so you need to copy all > facotries / factory methods... Not what I like... > > > Best regards, > Christian > > >> Am 13.03.2016 um 01:41 schrieb Remko Popma: >> Christian, would a JMX interface to this information suit your needs? >> Currently the AppenderAdminMBean does not provide much (if any) statistics >> on what was processed. This was partly deliberately because I did not want >> to build functionality when there's no real need for them and then later >> find that this functionality gets in the way. Now that there is a need we >> can start adding methods for getting statistics. >> >> If all you need to know is how many bytes were written, we could add some >> counters (number of events processed, number of bytes written) to >> AppenderAdminMBean. Your code would look something like this: >> >> String name = String.format(AppenderAdminMBean.PATTERN, loggerContextName, >> appenderName); >> ObjectName objectName = new ObjectName(name); >> MBeanServerConnection connection = >> ManagementFactory.getPlatformMBeanServer(); >> AppenderAdminMBean appender = JMX.newMBeanProxy(connection, objectName, >> AppenderAdminMBean.class, false); >> >> // now query the appender MBean to get the information you need >> appender.getNumberOfBytesWritten(); // this method does not exist yet >> >> >> If there are other reasons for overriding RollingFileManager, can you let >> us know what these are? >> >> Remko >> >> >>> On Thu, Mar 10, 2016 at 5:07 AM, Matt Sicker <[email protected]> wrote: >>> >>> Could be something neat to implement in JMX if it's monitoring he wants. >>> >>>> On 9 March 2016 at 11:51, Paul Benedict <[email protected]> wrote: >>>> >>>> Maybe... I think the user is not looking for a call back, per se, but >>> that >>>> was his initial solution for finding out statistics. Perhaps what he >>> really >>>> wants is a way to examine the throughput of log4j? >>>> >>>> Cheers, >>>> Paul >>>> >>>> On Wed, Mar 9, 2016 at 11:46 AM, Gary Gregory <[email protected]> >>>> wrote: >>>> >>>>> Maybe we need some (async?) notification where a call site could >>>> registered >>>>> a listener of some kind... >>>>> >>>>> Gary >>>>> >>>>>> On Wed, Mar 9, 2016 at 9:37 AM, Matt Sicker <[email protected]> wrote: >>>>>> >>>>>> Appenders are usually final because the appender itself doesn't do >>> much >>>>>> work (the managers do that), or at least that's what I gather. >>>>>> >>>>>>> On 16 February 2016 at 10:31, <[email protected]> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this is the first time I'm writing to a mailing list - I hope I >>> will >>>> do >>>>>>> it the right way :) >>>>>>> >>>>>>> >>>>>>> I migrated a few days ago from Log4J 1.2 to Log4J 2: In general I >>>> must >>>>>>> say: nice work guys and nice plugin system! >>>>>>> >>>>>>> But: I'm struggling with finding a way to get notice about the >>> exact >>>>>>> size of written bytes. I want to find a way how to do some stuff >>>> when X >>>>>>> bytes were written in Y seconds. I couldn't use a filter and check >>>> the >>>>>>> LogEvent because it's not possible to get the actual size of >>> written >>>>>>> bytes afterwards (because the layout will transform this...) >>>>>>> >>>>>>> I'm using a RollingFileAppender and could see, that this is using >>> the >>>>>>> RollingFileManager and the perfect way would be to hook into this >>>>>>> write(byte[]) method.. but I can't find how to do this. >>>>>>> >>>>>>> In general I would create a subclass and overwrite write(byte[]).. >>>> but >>>>>>> this is impossible because everything there is final. All >>> appenders, >>>>> all >>>>>>> appender managers, all layouts, ... and I think it's not the way it >>>>>>> should be when I create a new "MyRollingFileAppender" and copy all >>>> the >>>>>>> stuff and add the part I need to the write method. >>>>>>> >>>>>>> >>>>>>> So is there anybody who could maybe help and know a solution for >>> this >>>>>>> problem? And is there a specific reason that everything is final? >>> :( >>>>>>> >>>>>>> >>>>>>> Thank you in advance and best regards, >>>>>>> >>>>>>> Christian >>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: >>> [email protected] >>>>>> >>>>>> -- >>>>>> Matt Sicker <[email protected]> >>>>> >>>>> >>>>> -- >>>>> E-Mail: [email protected] | [email protected] >>>>> Java Persistence with Hibernate, Second Edition >>>>> <http://www.manning.com/bauer3/> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>> Blog: http://garygregory.wordpress.com >>>>> Home: http://garygregory.com/ >>>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> -- >>> Matt Sicker <[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]
