Hi Kirk, Thanks for the info, we were not aware of it. We are using filters in our configuration so we are not taking advantage of the optimization you mentioned. I think this is something that should be included in the documentation. I have created a PR: https://github.com/apache/geode/pull/4975(as its a small change I have not created a ticket but let me know if it is necessary to do so)
Anyway, for me its strange to see the difference between how it is decided to configure FastLogger to work on that way and how it is decided if the "change loglevel" command can be executed or not (both decisions are made in Log4jLoggingProvider ). On one hand, FastLogger is delegating the "is-Enabled" methods execution if the log level is debug or above or if there are filters in the log configuration. And on the other hand, "change loglevel" command is doing nothing when "the logging configuration is not the default" which is decided depending on the value of the geode-default property. I think this could be improved changing the requirement of the geode-default property for other more specific check/s, as it is done with FastLogger. The thing is that "change loglevel" command works fine for us if we force it, so I think that at least the way to force it should be in the documentation. If you have more info about what should be checked in the configuration instead of the geode-default property, I could implement it. BR/ Alberto ________________________________ De: Kirk Lund <kl...@apache.org> Enviado: miércoles, 8 de abril de 2020 18:27 Para: geode <dev@geode.apache.org> Asunto: Re: About "change loglevel" command This behavior has always worked like this since the internal implementation of logging changed from GemFire LogWriters to using Log4j. The reason is for performance. Geode is optimized for log level INFO with no filters -- it does this by wrapping all Log4j Loggers in a class called FastLogger which prevents Log4j from performing a bunch of filter checks as well as checking the timestamp of the log4j2.xml file. For some reason, the Log4j devs decided to have the check for changes to the configuration file occur within the thread performing a logging statement -- when this is allowed to happen, it kills the performance of Geode. So FastLogger has a volatile boolean that short circuits all of this extra checking, but it can only do this if the code can be sure that there are no filters and that the log level is INFO (or WARN or ERROR). Geode knows that it can bypass all of that extra Log4j behavior only if it's the default log4j2.xml that is bundled inside of the Geode jar (geode-core in older releases and now moved to geode-log4j). On Wed, Apr 8, 2020 at 8:40 AM Alberto Bustamante Reyes <alberto.bustamante.re...@est.tech> wrote: > Thanks Kirk. Could I ask what was the reason behind this change? In older > Geode version (1.10 I think) we were using our own log4j files, and the > command was working fine. > > Digging into the code I saw that its possible to start servers with a > system property (--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS) that also > allows the "change loglevel" command to work. I think that could be a > better alternative to document, as it is more command specific, instead of > documenting the "geode-default" property. > > For example (in italics the part that could be added to the documentation > of the command): > > "Changes the logging level on specified members. This command only will > take effect if the default Geode logging configuration is used. > > In case of using custom log4j configuration files, this command will not > work unless the member whose logging level you want to change was started > using the '--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS' system property." > > BR/ > > Alberto B. > > > > > ________________________________ > De: Kirk Lund <kl...@apache.org> > Enviado: martes, 7 de abril de 2020 0:17 > Para: geode <dev@geode.apache.org> > Asunto: Re: About "change loglevel" command > > Yes, this behavior is correct. If the User provides their own logging > configuration (or a different logging impl such as logback) then none of > the log-* configuration properties in Geode have any effect. > > On Mon, Apr 6, 2020 at 9:26 AM Alberto Bustamante Reyes > <alberto.bustamante.re...@est.tech> wrote: > > > Hi all, > > > > I have observed that "change loglevel" command doesn't work if the > > "log4j2.xml" file used doesn't contain the "geode-default" property set > to > > true. This requirement is not documented [1], so I would like to confirm > if > > this is the correct behavior. > > > > If we add "geode-default=true" in our log4j2 files, the "change loglevel" > > works fine, but Im not sure if its ok to use that property on a custom > log > > config file. > > > > Thanks, > > > > > > Alberto B. > > > > [1] > > > https://geode.apache.org/docs/guide/112/tools_modules/gfsh/command-pages/change.html > > > > >
