tl;dr; Should we be calling ThreadGroup.setMaxPriority in our ThreadGroups?
Any other thoughts on consistency in $subject?
Tomas Hofman has been doing some work cleaning up memory leaks that happen
when reload is called on a server, and one small one is ThreadGroup objects
leak. This is a small leak, as a ThreadGroup holds very little state if all
its threads have terminated. But it's good to clean things up, which has
led to a couple PRs:
Thinking about those got me thinking about how we use ThreadGroup in WF and
WF Core in general, and whether we should be more standard about it. Rather
than just discussing this on those PRs I figured I'd post here.
The first PR stores the TGs in constants. This works, but an alternative is
calling TG.setDaemon(true) on the thread group. Note that calling that
doesn't set a default for Thread.isDaemon() for the group's threads; all it
does is allow the TG to be terminated once all its threads terminate.
Which of these seems more appropriate depends on the intended lifecycle for
the threads; i.e. whether the expected thread count is at least one for the
lifetime of the group. Tomas' static field approach is more robust about
this. Calling setDaemon(true) on a TG stored in a constant is almost
A bit more interesting is Matej's approach in #17193. Here the TG is being
discarded. The effect of this is that the TG for the threads created by the
factory will be the TG of the thread that called the JBossThreadFactory
constructor. So, in this case, the TG of the MSC thread pool threads.
The basic downside of this approach is the code creating the
JBossThreadFactory has no idea what the settings of the current thread's TG
are and whether they are appropriate. It just assumes it's ok. However,
Matej's change doesn't actually change anything in this regard, since if
you create a new ThreadGroup and don't call setMaxPriority, your new TG
inherits the max priority from the current thread's TG.
It seems like if we create a new TG, we should call setMaxPriority on it,
unless we know what it has is ok.
I’ve been thinking lately how we could improve the documentation and user experience of WildFly.
My first task became what *is* already documented :)
It turns out that there are quite a lot of project that publish content under https://docs.wildfly.org/ even though they are not listed int its homepage.
I created https://github.com/wildfly/wildfly.github.io/issues/62 to gather information about it.
I’m not sure what to make of this information yet but this might prove useful to determine our plan of action.
Engineer @ Red Hat JBoss EAP