If you created a ThreadGroupContextSelector it probably would perform better,
but you might be trading one set of problems for another.
Ralph
> On Apr 29, 2019, at 11:58 AM, Benjamin Jaton <benjamin.ja...@gmail.com> wrote:
>
> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
