He makes a good argument. Also, since its an opt-in feature I cant see a problem with it being "verbose" by default.
k
kenkyee
03/09/2018, 2:01 PM
Failed yes, success no IMHO... would be easy too verbose and swamp the failure messages...
p
pavel
03/09/2018, 6:19 PM
Yes. Not logging success is an optimisation.
v
vonox7
03/10/2018, 12:12 AM
On my production system (running ktor in a kind-of heroku enviroment) I can âonlyâ post about 100 lines per second to stdout until the locking in some lower levels wonât allow ktor to response to request in reasonable time. So I would really prefer not to log success requests in INFO.
vonox7
03/10/2018, 12:14 AM
elizarov is right that the log is a typically starting point of investigation, but this wonât work any more when you have more than a few users per minute
o
orangy
03/10/2018, 9:16 AM
I think logging framework should allow switching levels dynamically at runtime, but SLF4J doesnât have it. Dropwizard for example employs logback directly and uses its facilities.
k
kenkyee
03/10/2018, 1:16 PM
I couldn't believe slf4j couldn't change logging levels at runtime so had to dig. Only workaround I found was this:
http://projects.lidalia.org.uk/lidalia-slf4j-ext/
But yep... that seems like a bug on slf4j đ