Hey, I just thought of another JMX feature: the ability to "flushBuffers".
This is something that I've wanted for years in log4j1: to reduce the logging performance penalty I usually use buffered IO with immediateFlush=false. That gives good performance, but the drawback is that if you want to see the most recent log events you are forced to wait until more events arrive that fill up the buffer and trigger a flush. If no more events arrive you're out of luck... The event you want to see is stuck in the buffer and you have no way to get it out. :-( The ability to flush all buffers would be a useful feature, and because I think it would usually be triggered manually rather than programmatically from an application, JMX is a good place to put it. Remko On 2013/04/06, at 0:42, "Jacob Kjome" <[email protected]> wrote: > > Fine, but let's not end up with another 479k jar (like Log4j-1.2.17) all in > the name of "fewer jars". Again, the option of an uber jar is fine for those > who don't care about bloating their application. But for those who want to > use Log4j2 purely for logging in their application, let's keep it minimal and > not bloat the jar up with a bunch of utility code that the application will > never make use of. > > > Jake > > On Wed, 3 Apr 2013 07:08:47 -0700 > Scott Deboy <[email protected]> wrote: >> +1 >> On Wed, Apr 3, 2013 at 4:35 AM, Gary Gregory <[email protected]> wrote: >>> The fewer jars the better IMO. >>> >>> Gary >>> >>> On Apr 3, 2013, at 5:53, Remko Popma <[email protected]> wrote: >>> >>> These all look doable. >>> >>> About Statistics from various components, @Ralph, anything in particular >>> you'd like to see? (If not, it is pretty easy to add them later.) >>> >>> Also, can the JMX related classes go into core or does this need a >>> separate module? >>> I would prefer core so that this is always available for users without >>> fiddling with extra jars. >>> Thoughts? >>> >>> >>> On 2013/04/03, at 9:35, Ralph Goers <[email protected]> wrote: >>> >>> Features I would like to see in JMX: >>> 1. Show all the LoggerContexts and their configurations. >>> 2. Ability to modify a configuration (this should involve cloning the >>> current configuration, modifying it and then replacing the prior >>> configuration with the new one). >>> 3. Statistics from various components. >>> 4. Display log output on the JMX console (at least the StatusLogger >>> output). >>> >>> >>> >>> >>> On Apr 2, 2013, at 12:38 AM, Remko Popma wrote: >>> >>> I would like to take a stab at implementing JMX support for log4j2. >>> >>> What features would you like to see with regards to JMX? Ideas are welcome! > > > --------------------------------------------------------------------- > 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]
