Re: [PROPOSAL] Change core logging from Java Utils Logging

2018-04-30 Thread msicker
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,

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-29 Thread Samuel Van Oort
> 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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-28 Thread Jesse Glick
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;

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-27 Thread Stephen Connolly
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)`

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-27 Thread Jesse Glick
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-22 Thread Stephen Connolly
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,

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-22 Thread Jesse Glick
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-20 Thread Stephen Connolly
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,

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-20 Thread Jesse Glick
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-19 Thread Oleg Nenashev
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-17 Thread Stephen Connolly
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-17 Thread Jesse Glick
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-11-17 Thread James Nord
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-12 Thread Robert Sandell
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-12 Thread Baptiste Mathus
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-12 Thread Cyrille Le Clerc
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,

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-12 Thread Jimilian
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-11 Thread Jesse Glick
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-11 Thread Stephen Connolly
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

Re: [PROPOSAL] Change core logging from Java Utils Logging

2017-04-11 Thread Jesse Glick
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