You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Benjamin Jaton <be...@gmail.com> on 2019/04/24 00:06:13 UTC
How to have a separate log file for a thread and all sub threads?
Hello,
Several times I've been in a situation where in a given JVM I am trying to
run distinct jobs in separate threads, who themselves might spawn their own
threads.
In those situations I usually want the logging of each job in a separate
log file, and that has proven to be difficult.
Log4j2 has a routing appender that allows to create a separate appender for
each job given that you can provide a routing key that's unique for each
job. But what key to use for this?
I've been using a ThreadContext variable that I set at the level of the job
thread, and any child thread that I have control over.
But the problem is that I don't always have control over this. Sometimes
third party APIs let you feed a custom ThreadFactory, sometimes they don't.
When they don't, I can't set that ThreadContext variable and part of the
job logging will be misrouted to a different appender.
Is there a way to work around this so that there is 1 log file for each job
that would gather all the logging of the sub threads?
Thanks,
Benjamin
Re: How to have a separate log file for a thread and all sub threads?
Posted by Matt Sicker <bo...@gmail.com>.
On Mon, 29 Apr 2019 at 14:18, Benjamin Jaton <be...@gmail.com> wrote:
> One thing I'm not sure about is how do you "set" the log level on a whole
> LoggerContext?
Take a look at Configurator. For example:
https://github.com/apache/logging-log4j2/blob/58d96d0e242eac260d5fe2317e54a6fc24332994/log4j-core/src/main/java/org/apache/logging/log4j/core/config/Configurator.java#L234
>
> On Mon, Apr 29, 2019 at 12:03 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > 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 <be...@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 <bo...@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 <be...@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.goers@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 <bo...@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.goers@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 <bo...@gmail.com> wrote:
> > >>>>>>>
> > >>>>>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
> > >> benjamin.jaton@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 <bo...@gmail.com>
> > >>>>>>>
> > >>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>>>>>> For additional commands, e-mail:
> > >> log4j-user-help@logging.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
You don’t. Each LoggerContext has its own hierarchy of Loggers. You would set the log level on the LoggerContext’s root Logger.
Ralph
> On Apr 29, 2019, at 12:18 PM, Benjamin Jaton <be...@gmail.com> wrote:
>
> Yes I've explored that route a little bit, inspired by the existing
> ClassLoaderContextSelector implementation.
>
> One thing I'm not sure about is how do you "set" the log level on a whole
> LoggerContext?
>
> On Mon, Apr 29, 2019 at 12:03 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> 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 <be...@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 <bo...@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 <be...@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.goers@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 <bo...@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.goers@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 <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
>>>> benjamin.jaton@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 <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
Yes I've explored that route a little bit, inspired by the existing
ClassLoaderContextSelector implementation.
One thing I'm not sure about is how do you "set" the log level on a whole
LoggerContext?
On Mon, Apr 29, 2019 at 12:03 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> 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 <be...@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 <bo...@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 <be...@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.goers@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 <bo...@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.goers@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 <bo...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
> >> benjamin.jaton@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 <bo...@gmail.com>
> >>>>>>>
> >>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>>> For additional commands, e-mail:
> >> log4j-user-help@logging.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Matt Sicker <bo...@gmail.com>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <be...@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 <bo...@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 <be...@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 <ra...@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 <bo...@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.goers@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 <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
>> benjamin.jaton@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 <bo...@gmail.com>
>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail:
>> log4j-user-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
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 <bo...@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 <be...@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 <ra...@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 <bo...@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.goers@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 <bo...@gmail.com> wrote:
> > > >>>
> > > >>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
> benjamin.jaton@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 <bo...@gmail.com>
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >>
> > > >
> > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Matt Sicker <bo...@gmail.com>.
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 <be...@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 <ra...@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 <bo...@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 <ra...@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 <bo...@gmail.com> wrote:
> > >>>
> > >>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
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 <ra...@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 <bo...@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 <ra...@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 <bo...@gmail.com> wrote:
> >>>
> >>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ra...@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 <bo...@gmail.com> wrote:
>>>
>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <bo...@gmail.com> wrote:
> >
> > On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@gmail.com> wrote:
>
> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Matt Sicker <bo...@gmail.com>.
On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <be...@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 <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
OK thanks. It's good to know the limitations, I think it's good enough for
my use case.
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?
On Wed, Apr 24, 2019 at 4:16 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> You could keep track of the ThreadGroups that represent jobs. Then
> traverse the parent of each ThreadGroup until one matches a registered job.
> But even this isn’t foolproof since the application can create a
> ThreadGroup with a parent ThreadGroup outside anything you know about. But
> I would think it would work in the majority of cases.
>
> Ralph
>
>
> > On Apr 24, 2019, at 1:53 PM, Benjamin Jaton <be...@gmail.com>
> wrote:
> >
> > Yes, indeed when I replace t1.run() with t1.start() it does output:
> > t1 threadgroup = mygroup
> > t2 threadgroup = mygroup
> > Thank you!
> >
> > So this could be a fine solution as long as the third party libs don't
> > override the ThreadGroup of the threads they create.
> > If they do override the threadgroup, there is no way to have 1 log file
> per
> > job correct?
> >
> > Thanks again for the help,
> > Benjamin
> >
> >
> >
> > On Wed, Apr 24, 2019 at 11:33 AM Ralph Goers <ralph.goers@dslextreme.com
> >
> > wrote:
> >
> >> The relevant section is -
> >>
> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
> >> <
> >>
> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
> >>> .
> >>
> >> Your test isn’t valid because you have 3 threads. The first is the main
> >> thread with a thread group of main, the second thread is created in the
> >> first Thread but directly associated with thread group “my group”. The
> >> third thread is created in thread “main” and so is in ThreadGroup main.
> >> While you may have created the third Thread within the scope of the
> second
> >> Thread Object, the code to create the third thread was not executed
> within
> >> the execution of Thread 2 as this program only has a single thread of
> >> execution. Thread 2 and 3 are never started.
> >>
> >> In other words Thread 3 must be executed from the call stack of Thread
> 2’s
> >> run method while Thread 2 is in control of the execution.
> >>
> >> Ralph
> >>
> >>> On Apr 24, 2019, at 9:21 AM, Benjamin Jaton <be...@gmail.com>
> >> wrote:
> >>>
> >>> Could you point me to the relevant section?
> >>>
> >>> I did the following test:
> >>> final ThreadGroup g = new ThreadGroup("mygroup");
> >>> Thread t1 = new Thread(g, () -> {
> >>> Thread t2 = new Thread(() -> { });
> >>> System.out.println("t2 threadgroup = " +
> t2.getThreadGroup().getName());
> >>> });
> >>> System.out.println("t1 threadgroup = " +
> t1.getThreadGroup().getName());
> >>> t1.run();
> >>>
> >>> And I get:
> >>> t1 threadgroup = mygroup
> >>> t2 threadgroup = main
> >>>
> >>> t2 is started from t1 yet didn't inherit the threadgroup. What am I
> >> missing?
> >>>
> >>> On Wed, Apr 24, 2019 at 6:05 AM Apache <ra...@dslextreme.com>
> >> wrote:
> >>>
> >>>> My reading of the javadoc for Thread indicates the do by default.
> >>>>
> >>>> Ralph
> >>>>
> >>>> On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <
> benjamin.jaton@gmail.com>
> >>>> wrote:
> >>>>
> >>>>>> If you want all the threads in a “job” then I would create the
> parent
> >>>>> thread with its own thread group and use the thread group name in the
> >>>>> lookup.
> >>>>>
> >>>>> But how do I assign the thread group to threads that 3rd party
> >> libraries
> >>>>> create? I don't think child threads naturally inherit the ThreadGroup
> >> of
> >>>>> their parents.
> >>>>>
> >>>>> On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <
> >> ralph.goers@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I think the solution is pretty simple. The RoutingAppender doesn’t
> >> only
> >>>>>> work with the ThreadContext. It works using a lookup. So if you were
> >> to
> >>>> use
> >>>>>> a ThreadLookup that used ${{thread:id}} you would get a new Appender
> >> for
> >>>>>> each thread id. To be honest, I am not sure why we haven’t created a
> >>>>>> ThreadLookup before. I could easily see multiple places were the
> >> thread
> >>>> id,
> >>>>>> name, priority or ThreadGroup name might want to be used.
> >>>>>>
> >>>>>> If you want all the threads in a “job” then I would create the
> parent
> >>>>>> thread with its own thread group and use the thread group name in
> the
> >>>>>> lookup.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <
> >> benjamin.jaton@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Several times I've been in a situation where in a given JVM I am
> >> trying
> >>>>>> to
> >>>>>>> run distinct jobs in separate threads, who themselves might spawn
> >> their
> >>>>>> own
> >>>>>>> threads.
> >>>>>>> In those situations I usually want the logging of each job in a
> >>>> separate
> >>>>>>> log file, and that has proven to be difficult.
> >>>>>>>
> >>>>>>> Log4j2 has a routing appender that allows to create a separate
> >> appender
> >>>>>> for
> >>>>>>> each job given that you can provide a routing key that's unique for
> >>>> each
> >>>>>>> job. But what key to use for this?
> >>>>>>> I've been using a ThreadContext variable that I set at the level of
> >> the
> >>>>>> job
> >>>>>>> thread, and any child thread that I have control over.
> >>>>>>>
> >>>>>>> But the problem is that I don't always have control over this.
> >>>> Sometimes
> >>>>>>> third party APIs let you feed a custom ThreadFactory, sometimes
> they
> >>>>>> don't.
> >>>>>>> When they don't, I can't set that ThreadContext variable and part
> of
> >>>> the
> >>>>>>> job logging will be misrouted to a different appender.
> >>>>>>>
> >>>>>>> Is there a way to work around this so that there is 1 log file for
> >> each
> >>>>>> job
> >>>>>>> that would gather all the logging of the sub threads?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Benjamin
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
You could keep track of the ThreadGroups that represent jobs. Then traverse the parent of each ThreadGroup until one matches a registered job. But even this isn’t foolproof since the application can create a ThreadGroup with a parent ThreadGroup outside anything you know about. But I would think it would work in the majority of cases.
Ralph
> On Apr 24, 2019, at 1:53 PM, Benjamin Jaton <be...@gmail.com> wrote:
>
> Yes, indeed when I replace t1.run() with t1.start() it does output:
> t1 threadgroup = mygroup
> t2 threadgroup = mygroup
> Thank you!
>
> So this could be a fine solution as long as the third party libs don't
> override the ThreadGroup of the threads they create.
> If they do override the threadgroup, there is no way to have 1 log file per
> job correct?
>
> Thanks again for the help,
> Benjamin
>
>
>
> On Wed, Apr 24, 2019 at 11:33 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> The relevant section is -
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
>> <
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
>>> .
>>
>> Your test isn’t valid because you have 3 threads. The first is the main
>> thread with a thread group of main, the second thread is created in the
>> first Thread but directly associated with thread group “my group”. The
>> third thread is created in thread “main” and so is in ThreadGroup main.
>> While you may have created the third Thread within the scope of the second
>> Thread Object, the code to create the third thread was not executed within
>> the execution of Thread 2 as this program only has a single thread of
>> execution. Thread 2 and 3 are never started.
>>
>> In other words Thread 3 must be executed from the call stack of Thread 2’s
>> run method while Thread 2 is in control of the execution.
>>
>> Ralph
>>
>>> On Apr 24, 2019, at 9:21 AM, Benjamin Jaton <be...@gmail.com>
>> wrote:
>>>
>>> Could you point me to the relevant section?
>>>
>>> I did the following test:
>>> final ThreadGroup g = new ThreadGroup("mygroup");
>>> Thread t1 = new Thread(g, () -> {
>>> Thread t2 = new Thread(() -> { });
>>> System.out.println("t2 threadgroup = " + t2.getThreadGroup().getName());
>>> });
>>> System.out.println("t1 threadgroup = " + t1.getThreadGroup().getName());
>>> t1.run();
>>>
>>> And I get:
>>> t1 threadgroup = mygroup
>>> t2 threadgroup = main
>>>
>>> t2 is started from t1 yet didn't inherit the threadgroup. What am I
>> missing?
>>>
>>> On Wed, Apr 24, 2019 at 6:05 AM Apache <ra...@dslextreme.com>
>> wrote:
>>>
>>>> My reading of the javadoc for Thread indicates the do by default.
>>>>
>>>> Ralph
>>>>
>>>> On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <be...@gmail.com>
>>>> wrote:
>>>>
>>>>>> If you want all the threads in a “job” then I would create the parent
>>>>> thread with its own thread group and use the thread group name in the
>>>>> lookup.
>>>>>
>>>>> But how do I assign the thread group to threads that 3rd party
>> libraries
>>>>> create? I don't think child threads naturally inherit the ThreadGroup
>> of
>>>>> their parents.
>>>>>
>>>>> On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <
>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> I think the solution is pretty simple. The RoutingAppender doesn’t
>> only
>>>>>> work with the ThreadContext. It works using a lookup. So if you were
>> to
>>>> use
>>>>>> a ThreadLookup that used ${{thread:id}} you would get a new Appender
>> for
>>>>>> each thread id. To be honest, I am not sure why we haven’t created a
>>>>>> ThreadLookup before. I could easily see multiple places were the
>> thread
>>>> id,
>>>>>> name, priority or ThreadGroup name might want to be used.
>>>>>>
>>>>>> If you want all the threads in a “job” then I would create the parent
>>>>>> thread with its own thread group and use the thread group name in the
>>>>>> lookup.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <
>> benjamin.jaton@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Several times I've been in a situation where in a given JVM I am
>> trying
>>>>>> to
>>>>>>> run distinct jobs in separate threads, who themselves might spawn
>> their
>>>>>> own
>>>>>>> threads.
>>>>>>> In those situations I usually want the logging of each job in a
>>>> separate
>>>>>>> log file, and that has proven to be difficult.
>>>>>>>
>>>>>>> Log4j2 has a routing appender that allows to create a separate
>> appender
>>>>>> for
>>>>>>> each job given that you can provide a routing key that's unique for
>>>> each
>>>>>>> job. But what key to use for this?
>>>>>>> I've been using a ThreadContext variable that I set at the level of
>> the
>>>>>> job
>>>>>>> thread, and any child thread that I have control over.
>>>>>>>
>>>>>>> But the problem is that I don't always have control over this.
>>>> Sometimes
>>>>>>> third party APIs let you feed a custom ThreadFactory, sometimes they
>>>>>> don't.
>>>>>>> When they don't, I can't set that ThreadContext variable and part of
>>>> the
>>>>>>> job logging will be misrouted to a different appender.
>>>>>>>
>>>>>>> Is there a way to work around this so that there is 1 log file for
>> each
>>>>>> job
>>>>>>> that would gather all the logging of the sub threads?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Benjamin
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
Yes, indeed when I replace t1.run() with t1.start() it does output:
t1 threadgroup = mygroup
t2 threadgroup = mygroup
Thank you!
So this could be a fine solution as long as the third party libs don't
override the ThreadGroup of the threads they create.
If they do override the threadgroup, there is no way to have 1 log file per
job correct?
Thanks again for the help,
Benjamin
On Wed, Apr 24, 2019 at 11:33 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> The relevant section is -
> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
> <
> https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable-
> >.
>
> Your test isn’t valid because you have 3 threads. The first is the main
> thread with a thread group of main, the second thread is created in the
> first Thread but directly associated with thread group “my group”. The
> third thread is created in thread “main” and so is in ThreadGroup main.
> While you may have created the third Thread within the scope of the second
> Thread Object, the code to create the third thread was not executed within
> the execution of Thread 2 as this program only has a single thread of
> execution. Thread 2 and 3 are never started.
>
> In other words Thread 3 must be executed from the call stack of Thread 2’s
> run method while Thread 2 is in control of the execution.
>
> Ralph
>
> > On Apr 24, 2019, at 9:21 AM, Benjamin Jaton <be...@gmail.com>
> wrote:
> >
> > Could you point me to the relevant section?
> >
> > I did the following test:
> > final ThreadGroup g = new ThreadGroup("mygroup");
> > Thread t1 = new Thread(g, () -> {
> > Thread t2 = new Thread(() -> { });
> > System.out.println("t2 threadgroup = " + t2.getThreadGroup().getName());
> > });
> > System.out.println("t1 threadgroup = " + t1.getThreadGroup().getName());
> > t1.run();
> >
> > And I get:
> > t1 threadgroup = mygroup
> > t2 threadgroup = main
> >
> > t2 is started from t1 yet didn't inherit the threadgroup. What am I
> missing?
> >
> > On Wed, Apr 24, 2019 at 6:05 AM Apache <ra...@dslextreme.com>
> wrote:
> >
> >> My reading of the javadoc for Thread indicates the do by default.
> >>
> >> Ralph
> >>
> >> On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <be...@gmail.com>
> >> wrote:
> >>
> >>>> If you want all the threads in a “job” then I would create the parent
> >>> thread with its own thread group and use the thread group name in the
> >>> lookup.
> >>>
> >>> But how do I assign the thread group to threads that 3rd party
> libraries
> >>> create? I don't think child threads naturally inherit the ThreadGroup
> of
> >>> their parents.
> >>>
> >>> On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> >>> wrote:
> >>>
> >>>> I think the solution is pretty simple. The RoutingAppender doesn’t
> only
> >>>> work with the ThreadContext. It works using a lookup. So if you were
> to
> >> use
> >>>> a ThreadLookup that used ${{thread:id}} you would get a new Appender
> for
> >>>> each thread id. To be honest, I am not sure why we haven’t created a
> >>>> ThreadLookup before. I could easily see multiple places were the
> thread
> >> id,
> >>>> name, priority or ThreadGroup name might want to be used.
> >>>>
> >>>> If you want all the threads in a “job” then I would create the parent
> >>>> thread with its own thread group and use the thread group name in the
> >>>> lookup.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <
> benjamin.jaton@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Several times I've been in a situation where in a given JVM I am
> trying
> >>>> to
> >>>>> run distinct jobs in separate threads, who themselves might spawn
> their
> >>>> own
> >>>>> threads.
> >>>>> In those situations I usually want the logging of each job in a
> >> separate
> >>>>> log file, and that has proven to be difficult.
> >>>>>
> >>>>> Log4j2 has a routing appender that allows to create a separate
> appender
> >>>> for
> >>>>> each job given that you can provide a routing key that's unique for
> >> each
> >>>>> job. But what key to use for this?
> >>>>> I've been using a ThreadContext variable that I set at the level of
> the
> >>>> job
> >>>>> thread, and any child thread that I have control over.
> >>>>>
> >>>>> But the problem is that I don't always have control over this.
> >> Sometimes
> >>>>> third party APIs let you feed a custom ThreadFactory, sometimes they
> >>>> don't.
> >>>>> When they don't, I can't set that ThreadContext variable and part of
> >> the
> >>>>> job logging will be misrouted to a different appender.
> >>>>>
> >>>>> Is there a way to work around this so that there is 1 log file for
> each
> >>>> job
> >>>>> that would gather all the logging of the sub threads?
> >>>>>
> >>>>> Thanks,
> >>>>> Benjamin
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
The relevant section is - https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable- <https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#Thread-java.lang.ThreadGroup-java.lang.Runnable->.
Your test isn’t valid because you have 3 threads. The first is the main thread with a thread group of main, the second thread is created in the first Thread but directly associated with thread group “my group”. The third thread is created in thread “main” and so is in ThreadGroup main. While you may have created the third Thread within the scope of the second Thread Object, the code to create the third thread was not executed within the execution of Thread 2 as this program only has a single thread of execution. Thread 2 and 3 are never started.
In other words Thread 3 must be executed from the call stack of Thread 2’s run method while Thread 2 is in control of the execution.
Ralph
> On Apr 24, 2019, at 9:21 AM, Benjamin Jaton <be...@gmail.com> wrote:
>
> Could you point me to the relevant section?
>
> I did the following test:
> final ThreadGroup g = new ThreadGroup("mygroup");
> Thread t1 = new Thread(g, () -> {
> Thread t2 = new Thread(() -> { });
> System.out.println("t2 threadgroup = " + t2.getThreadGroup().getName());
> });
> System.out.println("t1 threadgroup = " + t1.getThreadGroup().getName());
> t1.run();
>
> And I get:
> t1 threadgroup = mygroup
> t2 threadgroup = main
>
> t2 is started from t1 yet didn't inherit the threadgroup. What am I missing?
>
> On Wed, Apr 24, 2019 at 6:05 AM Apache <ra...@dslextreme.com> wrote:
>
>> My reading of the javadoc for Thread indicates the do by default.
>>
>> Ralph
>>
>> On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <be...@gmail.com>
>> wrote:
>>
>>>> If you want all the threads in a “job” then I would create the parent
>>> thread with its own thread group and use the thread group name in the
>>> lookup.
>>>
>>> But how do I assign the thread group to threads that 3rd party libraries
>>> create? I don't think child threads naturally inherit the ThreadGroup of
>>> their parents.
>>>
>>> On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> I think the solution is pretty simple. The RoutingAppender doesn’t only
>>>> work with the ThreadContext. It works using a lookup. So if you were to
>> use
>>>> a ThreadLookup that used ${{thread:id}} you would get a new Appender for
>>>> each thread id. To be honest, I am not sure why we haven’t created a
>>>> ThreadLookup before. I could easily see multiple places were the thread
>> id,
>>>> name, priority or ThreadGroup name might want to be used.
>>>>
>>>> If you want all the threads in a “job” then I would create the parent
>>>> thread with its own thread group and use the thread group name in the
>>>> lookup.
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <be...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Several times I've been in a situation where in a given JVM I am trying
>>>> to
>>>>> run distinct jobs in separate threads, who themselves might spawn their
>>>> own
>>>>> threads.
>>>>> In those situations I usually want the logging of each job in a
>> separate
>>>>> log file, and that has proven to be difficult.
>>>>>
>>>>> Log4j2 has a routing appender that allows to create a separate appender
>>>> for
>>>>> each job given that you can provide a routing key that's unique for
>> each
>>>>> job. But what key to use for this?
>>>>> I've been using a ThreadContext variable that I set at the level of the
>>>> job
>>>>> thread, and any child thread that I have control over.
>>>>>
>>>>> But the problem is that I don't always have control over this.
>> Sometimes
>>>>> third party APIs let you feed a custom ThreadFactory, sometimes they
>>>> don't.
>>>>> When they don't, I can't set that ThreadContext variable and part of
>> the
>>>>> job logging will be misrouted to a different appender.
>>>>>
>>>>> Is there a way to work around this so that there is 1 log file for each
>>>> job
>>>>> that would gather all the logging of the sub threads?
>>>>>
>>>>> Thanks,
>>>>> Benjamin
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
Could you point me to the relevant section?
I did the following test:
final ThreadGroup g = new ThreadGroup("mygroup");
Thread t1 = new Thread(g, () -> {
Thread t2 = new Thread(() -> { });
System.out.println("t2 threadgroup = " + t2.getThreadGroup().getName());
});
System.out.println("t1 threadgroup = " + t1.getThreadGroup().getName());
t1.run();
And I get:
t1 threadgroup = mygroup
t2 threadgroup = main
t2 is started from t1 yet didn't inherit the threadgroup. What am I missing?
On Wed, Apr 24, 2019 at 6:05 AM Apache <ra...@dslextreme.com> wrote:
> My reading of the javadoc for Thread indicates the do by default.
>
> Ralph
>
> On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <be...@gmail.com>
> wrote:
>
> >> If you want all the threads in a “job” then I would create the parent
> > thread with its own thread group and use the thread group name in the
> > lookup.
> >
> > But how do I assign the thread group to threads that 3rd party libraries
> > create? I don't think child threads naturally inherit the ThreadGroup of
> > their parents.
> >
> > On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> I think the solution is pretty simple. The RoutingAppender doesn’t only
> >> work with the ThreadContext. It works using a lookup. So if you were to
> use
> >> a ThreadLookup that used ${{thread:id}} you would get a new Appender for
> >> each thread id. To be honest, I am not sure why we haven’t created a
> >> ThreadLookup before. I could easily see multiple places were the thread
> id,
> >> name, priority or ThreadGroup name might want to be used.
> >>
> >> If you want all the threads in a “job” then I would create the parent
> >> thread with its own thread group and use the thread group name in the
> >> lookup.
> >>
> >> Ralph
> >>
> >>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <be...@gmail.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Several times I've been in a situation where in a given JVM I am trying
> >> to
> >>> run distinct jobs in separate threads, who themselves might spawn their
> >> own
> >>> threads.
> >>> In those situations I usually want the logging of each job in a
> separate
> >>> log file, and that has proven to be difficult.
> >>>
> >>> Log4j2 has a routing appender that allows to create a separate appender
> >> for
> >>> each job given that you can provide a routing key that's unique for
> each
> >>> job. But what key to use for this?
> >>> I've been using a ThreadContext variable that I set at the level of the
> >> job
> >>> thread, and any child thread that I have control over.
> >>>
> >>> But the problem is that I don't always have control over this.
> Sometimes
> >>> third party APIs let you feed a custom ThreadFactory, sometimes they
> >> don't.
> >>> When they don't, I can't set that ThreadContext variable and part of
> the
> >>> job logging will be misrouted to a different appender.
> >>>
> >>> Is there a way to work around this so that there is 1 log file for each
> >> job
> >>> that would gather all the logging of the sub threads?
> >>>
> >>> Thanks,
> >>> Benjamin
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Apache <ra...@dslextreme.com>.
My reading of the javadoc for Thread indicates the do by default.
Ralph
On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <be...@gmail.com> wrote:
>> If you want all the threads in a “job” then I would create the parent
> thread with its own thread group and use the thread group name in the
> lookup.
>
> But how do I assign the thread group to threads that 3rd party libraries
> create? I don't think child threads naturally inherit the ThreadGroup of
> their parents.
>
> On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I think the solution is pretty simple. The RoutingAppender doesn’t only
>> work with the ThreadContext. It works using a lookup. So if you were to use
>> a ThreadLookup that used ${{thread:id}} you would get a new Appender for
>> each thread id. To be honest, I am not sure why we haven’t created a
>> ThreadLookup before. I could easily see multiple places were the thread id,
>> name, priority or ThreadGroup name might want to be used.
>>
>> If you want all the threads in a “job” then I would create the parent
>> thread with its own thread group and use the thread group name in the
>> lookup.
>>
>> Ralph
>>
>>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <be...@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> Several times I've been in a situation where in a given JVM I am trying
>> to
>>> run distinct jobs in separate threads, who themselves might spawn their
>> own
>>> threads.
>>> In those situations I usually want the logging of each job in a separate
>>> log file, and that has proven to be difficult.
>>>
>>> Log4j2 has a routing appender that allows to create a separate appender
>> for
>>> each job given that you can provide a routing key that's unique for each
>>> job. But what key to use for this?
>>> I've been using a ThreadContext variable that I set at the level of the
>> job
>>> thread, and any child thread that I have control over.
>>>
>>> But the problem is that I don't always have control over this. Sometimes
>>> third party APIs let you feed a custom ThreadFactory, sometimes they
>> don't.
>>> When they don't, I can't set that ThreadContext variable and part of the
>>> job logging will be misrouted to a different appender.
>>>
>>> Is there a way to work around this so that there is 1 log file for each
>> job
>>> that would gather all the logging of the sub threads?
>>>
>>> Thanks,
>>> Benjamin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: How to have a separate log file for a thread and all sub threads?
Posted by Benjamin Jaton <be...@gmail.com>.
> If you want all the threads in a “job” then I would create the parent
thread with its own thread group and use the thread group name in the
lookup.
But how do I assign the thread group to threads that 3rd party libraries
create? I don't think child threads naturally inherit the ThreadGroup of
their parents.
On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> I think the solution is pretty simple. The RoutingAppender doesn’t only
> work with the ThreadContext. It works using a lookup. So if you were to use
> a ThreadLookup that used ${{thread:id}} you would get a new Appender for
> each thread id. To be honest, I am not sure why we haven’t created a
> ThreadLookup before. I could easily see multiple places were the thread id,
> name, priority or ThreadGroup name might want to be used.
>
> If you want all the threads in a “job” then I would create the parent
> thread with its own thread group and use the thread group name in the
> lookup.
>
> Ralph
>
> > On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <be...@gmail.com>
> wrote:
> >
> > Hello,
> >
> > Several times I've been in a situation where in a given JVM I am trying
> to
> > run distinct jobs in separate threads, who themselves might spawn their
> own
> > threads.
> > In those situations I usually want the logging of each job in a separate
> > log file, and that has proven to be difficult.
> >
> > Log4j2 has a routing appender that allows to create a separate appender
> for
> > each job given that you can provide a routing key that's unique for each
> > job. But what key to use for this?
> > I've been using a ThreadContext variable that I set at the level of the
> job
> > thread, and any child thread that I have control over.
> >
> > But the problem is that I don't always have control over this. Sometimes
> > third party APIs let you feed a custom ThreadFactory, sometimes they
> don't.
> > When they don't, I can't set that ThreadContext variable and part of the
> > job logging will be misrouted to a different appender.
> >
> > Is there a way to work around this so that there is 1 log file for each
> job
> > that would gather all the logging of the sub threads?
> >
> > Thanks,
> > Benjamin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: How to have a separate log file for a thread and all sub threads?
Posted by Ralph Goers <ra...@dslextreme.com>.
I think the solution is pretty simple. The RoutingAppender doesn’t only work with the ThreadContext. It works using a lookup. So if you were to use a ThreadLookup that used ${{thread:id}} you would get a new Appender for each thread id. To be honest, I am not sure why we haven’t created a ThreadLookup before. I could easily see multiple places were the thread id, name, priority or ThreadGroup name might want to be used.
If you want all the threads in a “job” then I would create the parent thread with its own thread group and use the thread group name in the lookup.
Ralph
> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <be...@gmail.com> wrote:
>
> Hello,
>
> Several times I've been in a situation where in a given JVM I am trying to
> run distinct jobs in separate threads, who themselves might spawn their own
> threads.
> In those situations I usually want the logging of each job in a separate
> log file, and that has proven to be difficult.
>
> Log4j2 has a routing appender that allows to create a separate appender for
> each job given that you can provide a routing key that's unique for each
> job. But what key to use for this?
> I've been using a ThreadContext variable that I set at the level of the job
> thread, and any child thread that I have control over.
>
> But the problem is that I don't always have control over this. Sometimes
> third party APIs let you feed a custom ThreadFactory, sometimes they don't.
> When they don't, I can't set that ThreadContext variable and part of the
> job logging will be misrouted to a different appender.
>
> Is there a way to work around this so that there is 1 log file for each job
> that would gather all the logging of the sub threads?
>
> Thanks,
> Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org