logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: Log4j should manage it's own threads
Date Thu, 14 Jul 2016 21:12:42 GMT
I think sending you to these links will help the most:

https://jcp.org/aboutJava/communityprocess/ec-public/materials/2013-01-1516/JSR236-EC-F2F-Jan2013.pdf

https://www.javacodegeeks.com/2014/07/java-ee-concurrency-api-tutorial.html

Cheers,
Paul

On Thu, Jul 14, 2016 at 4:10 PM, Gary Gregory <garydgregory@gmail.com>
wrote:

> On Thu, Jul 14, 2016 at 1:07 PM, Paul Benedict <pbenedict@apache.org>
> wrote:
>
>> In an EE environment, don't create your own threads. If you do create
>> your own threads, the EE server has no way to shut them down when an
>> application gets undeployed. You'd want to have the EE server manage the
>> thread creations.
>>
>
> What's the J2EE way to ask for a thread or submit a job?
>
> Gary
>
>
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <garydgregory@gmail.com>
>> wrote:
>>
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boards@gmail.com> wrote:
>>>
>>>> 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>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>
>
> --
> 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
>

Mime
View raw message