I ended up making a DynamicThreadholdFilter to be able to resolve the log
level dynamically.
What's not so great is that this management of the log level with a "post"
filter requires the logger to let everything through (TRACE).
So then methods like isDebugEnabled() will always return true.
Anyways for my use case we'll have to go with this as we need a log level
per job (threadgroup).
On Mon, Apr 29, 2019 at 11:43 AM Matt Sicker <boa...@gmail.com> wrote:
> Requiring the use of ThreadContext data everywhere can slow things
> down a little, though not sure by how much.
>
> On Thu, 25 Apr 2019 at 13:35, Benjamin Jaton <benjamin.ja...@gmail.com>
> wrote:
> >
> > I've used ThresholdFilter to have the log level check at the level of the
> > (sub) appender:
> >
> > "ThresholdFilter": {
> > "level": "${my:threadgroup.jobLogLevel}",
> > "onMatch": "ACCEPT",
> > "onMismatch": "DENY"
> > }
> >
> > Of course then I need to have the root logger in TRACE to let everything
> in
> > to be filtered later on by the appender:
> >
> > "loggers": {
> > "root": {
> > "level": "TRACE",
> > "additivity": "false",
> > "includeLocation": "true",
> > "AppenderRef": {
> > "ref": "JobsRoutingAppender"
> > }
> > }
> > }
> >
> > What do you think of this?
> > Is performance a concern with this approach?
> >
> > On Thu, Apr 25, 2019 at 9:33 AM Ralph Goers <ralph.go...@dslextreme.com>
> > wrote:
> >
> > > Another possibility would be to have a ThreadGroupContextSelector and
> then
> > > use a different LoggerContext and configuration for each ThreadGroup.
> > > However, that could get very complicated. The RoutingAppender pretty
> much
> > > accomplishes the same thing and would be much easier to do.
> > >
> > > Ralph
> > >
> > > > On Apr 25, 2019, at 9:21 AM, Matt Sicker <boa...@gmail.com> wrote:
> > > >
> > > > Oh damn, right, bit of a limitation there. I'll ponder on this a bit.
> > > >
> > > > On Thu, 25 Apr 2019 at 11:18, Ralph Goers <
> ralph.go...@dslextreme.com>
> > > wrote:
> > > >>
> > > >> Matt, Benjamin’s issue is that he has no control over what is
> running
> > > in the “jobs” but he wants all the logs for a “job” to end up in the
> same
> > > appender. His definition of a job is that he is creating a thread to
> run it
> > > and everything under that thread should route to that Appender. So he
> > > cannot control what logger names are used much less whether they have
> > > Markers or not.
> > > >>
> > > >> Ralph
> > > >>
> > > >>> On Apr 25, 2019, at 8:59 AM, Matt Sicker <boa...@gmail.com> wrote:
> > > >>>
> > > >>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
> benjamin.ja...@gmail.com>
> > > wrote:
> > > >>>> I've implemented the solution based on ThreadGroups. Now I am
> trying
> > > to
> > > >>>> have a separate log level per job. The goal is to be able to set
> one
> > > job in
> > > >>>> DEBUG or TRACE while the others stay in WARN. Possible?
> > > >>>> The RoutingAppender creates an appender per route but as far as I
> > > know I
> > > >>>> cannot set a log level on the appender object. I guess filters
> could
> > > be
> > > >>>> used but is there something simpler I'm missing?
> > > >>>
> > > >>> I think you'd be better off using markers for that. See
> > > >>> https://logging.apache.org/log4j/2.x/manual/markers.html
> > > >>>
> > > >>> You might also be able to just use a naming scheme for your loggers
> > > >>> that automatically makes them separately configurable as typical
> > > >>> loggers. For example, say you use a naming scheme
> > > >>> "com.example.threadgroup.<groupName>" as your loggers. Then you
> could
> > > >>> configure them by name as usual.
> > > >>>
> > > >>> --
> > > >>> Matt Sicker <boa...@gmail.com>
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > >>> For additional commands, e-mail:
> log4j-user-h...@logging.apache.org
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > > >>
> > > >
> > > >
> > > > --
> > > > Matt Sicker <boa...@gmail.com>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > >
> > >
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>
