You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alberto Bustamante Reyes <al...@est.tech> on 2020/04/06 16:26:29 UTC
About "change loglevel" command
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
RE: About "change loglevel" command
Posted by Alberto Bustamante Reyes <al...@est.tech>.
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 <de...@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
<al...@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 <de...@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
> <al...@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
> >
> >
>
Re: About "change loglevel" command
Posted by Kirk Lund <kl...@apache.org>.
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
<al...@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 <de...@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
> <al...@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
> >
> >
>
RE: About "change loglevel" command
Posted by Alberto Bustamante Reyes <al...@est.tech>.
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 <de...@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
<al...@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
>
>
Re: About "change loglevel" command
Posted by Kirk Lund <kl...@apache.org>.
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
<al...@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
>
>