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.ja...@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.go...@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.ja...@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.go...@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.ja...@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.go...@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.ja...@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-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 >>>> >>>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
