logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Log4j should manage it's own threads
Date Thu, 14 Jul 2016 18:35:26 GMT
Anyone wanna make a jira ticket for this? I'm not sure on how best to
describe this.

On 5 July 2016 at 09:00, Matt Sicker <boards@gmail.com> wrote:

> I'm not sure how many threads we spawn are actually reusable, but
> gathering them into a single pool would definitely help figure out which
> ones can be used.
>
> Also, would this be vaguely related to the custom Log4j ThreadLocal object
> we were thinking about a little while ago?
>
> On 5 July 2016 at 04:52, Mikael Ståldal <mikael.staldal@magine.com> wrote:
>
>> Sounds like a good idea. I think it's also good to reuse threads for
>> performance.
>>
>> On Mon, Jul 4, 2016 at 10:00 PM, Matt Sicker <boards@gmail.com> wrote:
>>
>>> This sounds like an interesting idea worth pursuing.
>>>
>>> On 4 July 2016 at 14:56, Gary Gregory <garydgregory@gmail.com> wrote:
>>>
>>>> When I see code like:
>>>>
>>>>                     LOGGER.debug("RollingFileManager executing async
>>>> {}", descriptor.getAsynchronous());
>>>>                     thread = new Log4jThread(new
>>>> AsyncAction(descriptor.getAsynchronous(), this));
>>>>                     thread.start();
>>>>
>>>> and:
>>>>
>>>>             final Thread thread = new Log4jThread(new
>>>> ReconfigurationWorker(listener, reconfigurable));
>>>>             thread.setDaemon(true);
>>>>             thread.start();
>>>>
>>>> and other places, I think: "and poof, I've lost track of that thread".
>>>>
>>>> What if we used a thread pool (ExecutorService) to track all of our
>>>> threads? This would allow for at least trying for an orderly shutdown. This
>>>> would avoid problems like one part of an app thinking that rollovers should
>>>> be done when they are not because a log4j context has been stopped (like
in
>>>> our test probably) but the rollover thread is still going about doing its
>>>> work.
>>>>
>>>> This would be for 2.7 I think.
>>>>
>>>> We could then have a different context stop API, maybe with a timeout
>>>> or not, something like ExecutorService's shutdown() vs. shutdownNow().
>>>>
>>>> Thoughts?
>>>>
>>>> Happy 4th!
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message