logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: How to have a separate log file for a thread and all sub threads?
Date Wed, 24 Apr 2019 23:16:01 GMT
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 <benjamin.jaton@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 <benjamin.jaton@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 <ralph.goers@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


Mime
View raw message