Hey all, sorry to resurrect an old thread, but I'm also interested in
migrating. I'm a developer of Log4j 2 and could probably spend hours
geeking out about this, but for us developers, the best advantage of
migrating to log4j-api or slf4j-api would be parameterized logging,
markers,
> Am I the only one to think it strange that we are discussing using
very limited core developer resources to replace a library used
pervasively throughout the Jenkins code base with a functionally
identical library with no demonstrable benefit to users and rather
marginal impact on developers
On Mon, Nov 27, 2017 at 7:56 PM, Stephen Connolly
wrote:
> any other user provided handler could [also queue unformatted log records]
Theoretically. I cannot think of any such case. Handlers are known to
be registered by Jenkins core; the `support-core` plugin;
On Mon 27 Nov 2017 at 22:51, Jesse Glick wrote:
> On Wed, Nov 22, 2017 at 2:07 PM, Stephen Connolly
> wrote:
> > there is the logging of incorrect values
>
> I guess this is a concern according to the handler.
> `Logger.log(LogRecord)`
On Wed, Nov 22, 2017 at 2:07 PM, Stephen Connolly
wrote:
> there is the logging of incorrect values
I guess this is a concern according to the handler.
`Logger.log(LogRecord)` calls `Handler.publish` synchronously. And
typical handlers would then format the
On Wed 22 Nov 2017 at 17:26, Jesse Glick wrote:
> On Mon, Nov 20, 2017 at 10:32 AM, Stephen Connolly
> wrote:
> > log(Level.FINE, ()-> "simple concat " + localVar)
> >
> > is worse when not logging than either of
> >
> > log(Level.FINE,
On Mon, Nov 20, 2017 at 10:32 AM, Stephen Connolly
wrote:
> log(Level.FINE, ()-> "simple concat " + localVar)
>
> is worse when not logging than either of
>
> log(Level.FINE, "simple concat {0}", localVar)
> log(Level.FINE, "simple concat {0}", new
JMH is the micro benchmarking tool.
INDY is invoke dynamic
I have blog posts already published showing that when capturing local
variables,
log(Level.FINE, ()-> "simple concat " + localVar)
is worse when not logging than either of
log(Level.FINE, "simple concat {0}", localVar)
log(Level.FINE,
On Fri, Nov 17, 2017 at 10:41 AM, Stephen Connolly
wrote:
> JMH says Indy is slower
Sorry, what are “JMH” and “Indy”?
Where is the evidence that there is any actual performance issue in
production Jenkins installations which is not trivially corrected by a
JEP It, I'd guess.
I am +1 about considering the move, but it requires some design work and
prototyping.
BR, Oleg
пятница, 17 ноября 2017 г., 16:41:51 UTC+1 пользователь Stephen Connolly
написал:
>
>
> On Fri 17 Nov 2017 at 15:34, Jesse Glick > wrote:
>
>> On Fri, Nov
On Fri 17 Nov 2017 at 15:34, Jesse Glick wrote:
> On Fri, Nov 17, 2017 at 8:47 AM, James Nord wrote:
> > I just found myself having to write a
> > LogRecord to log a paramaterized log with an exception...
>
> LOGGER.log(Level.FINE, ex, () -> "so why
On Fri, Nov 17, 2017 at 8:47 AM, James Nord wrote:
> I just found myself having to write a
> LogRecord to log a paramaterized log with an exception...
LOGGER.log(Level.FINE, ex, () -> "so why did you bother making a
LogRecord for " + this + " common task?");
--
You
Bringing this up again because I just found myself having to write a
LogRecord to log a paramaterized log with an exception...
What is the actual overhead of using the bridge? Stephen has some winderful
benchmarks of not logging or logging various paramters but I didn't see
anything about
Stephen has shot down my previous proposals to switch to using SLF4J before
because of the SLF4J -> JUL bridge has terrible overhead in performance. So
if we were to switch to SLF4J we also need to switch the default logging
backend because otherwise we would really have a performance issue even
I'm somehow +0.9 for moving away from JUL, and -0.5 to move to anything
else than the SLF4J facade (pleonasm). The API is easy to use and we can
delay or switch to another impl without touching the code.
I am not that convinced that apart from rare cases where people enabled
more logging for
I prefer the SLF4J syntax to the java.util.logging syntax, I don't like at
all the java.util.logging syntax.
I think that using a friendly logging API is a good reason to move away
from java.util.logging.
Cyrille
On Tuesday, April 11, 2017 at 4:25:10 PM UTC+2, Jesse Glick wrote:
>
> On Tue,
Hi
Our Jenkins instance* produces ~10 messages per second maximum (INFO
mainly), but I didn't see anything suspicious in any profiler report
related to logging system.
Maybe I looked for something wrong in profiler reports, but I checked:
1) Locked threads
2) CPU
3) IO
4) Memory
But in
On Tue, Apr 11, 2017 at 11:35 AM, Stephen Connolly
wrote:
> you still are 50% slower due to poor message
> formatting and always capturing the stack trace
But again what is the actual impact on a typical instance producing on
the order of one log message per
Even if you buffer the loggers you still are 50% slower due to poor message
formatting and always capturing the stack trace for every log message to be
able to report the call site
On 11 April 2017 at 15:25, Jesse Glick wrote:
> On Tue, Apr 11, 2017 at 9:14 AM, Stephen
On Tue, Apr 11, 2017 at 9:14 AM, Stephen Connolly
wrote:
> Java Utils Logging is horrible in terms of performance.
All I see from a quick read is that unbuffered handlers are a problem
if you are in fact logging tons of messages. In normal operation
Jenkins does
20 matches
Mail list logo