You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/07/04 19:56:36 UTC
Log4j should manage it's own threads
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
Re: Log4j should manage it's own threads
Posted by Gary Gregory <ga...@gmail.com>.
The implementation of https://issues.apache.org/jira/browse/LOG4J2-1539 "Add
Core API Configurator.shutdown(LoggerContext, long, TimeUnit)" wraps up
this thread.
Gary
On Mon, Jul 4, 2016 at 12:56 PM, Gary Gregory <ga...@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
>
--
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
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
I was thinking more along the lines of users installing it themselves. If I
were running more than one webapp in my Tomcat instance, I'd just put it in
$CATALINA_HOME/lib. Providing an easy way to upgrade is also useful.
I could have sworn one of the JEE servers came with log4j2 nowadays, but I
can't figure out which one (if any). I thought maybe Wildfly or Weblogic
were, but I can't find any documentation backing that up.
On 14 July 2016 at 18:57, Ralph Goers <ra...@dslextreme.com> wrote:
> Actually, I either wish they wouldn’t or do it in such a way that it
> doesn’t impact the application’s classpath. Many applications will want to
> use newer versions that whatever version the container ships with.
>
> Ralph
>
> On Jul 14, 2016, at 4:44 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I mean ideally, log4j should be running as a server library. Some of the
> JEE servers come with log4j 2 out of the box I think.
>
> On 14 July 2016 at 16:36, Paul Benedict <pb...@apache.org> wrote:
>
>> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0
>> thing :-) but it would be really awesome if Log4J could advertise itself as
>> EE compatible with threading. Just my 2 cents. When it comes to the
>> refactoring, you'll just want to have a good abstraction built so you can
>> plug in the right implementation at runtime (non-container vs container).
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> I’m not aware that frameworks like Log4j actually adhere to those
>>> guidelines. It is too difficult to write code that works in both the JEE
>>> and non-JEE environments.
>>>
>>> Ralph
>>>
>>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> I'll get around to it ;-)
>>>>
>>>> Gary
>>>>
>>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>>
>>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@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
>>>>
>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j should manage it's own threads
Posted by Ralph Goers <ra...@dslextreme.com>.
Actually, I either wish they wouldn’t or do it in such a way that it doesn’t impact the application’s classpath. Many applications will want to use newer versions that whatever version the container ships with.
Ralph
> On Jul 14, 2016, at 4:44 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I mean ideally, log4j should be running as a server library. Some of the JEE servers come with log4j 2 out of the box I think.
>
> On 14 July 2016 at 16:36, Paul Benedict <pbenedict@apache.org <ma...@apache.org>> wrote:
> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0 thing :-) but it would be really awesome if Log4J could advertise itself as EE compatible with threading. Just my 2 cents. When it comes to the refactoring, you'll just want to have a good abstraction built so you can plug in the right implementation at runtime (non-container vs container).
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I’m not aware that frameworks like Log4j actually adhere to those guidelines. It is too difficult to write code that works in both the JEE and non-JEE environments.
>
> Ralph
>
>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pbenedict@apache.org <ma...@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.
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>> I'll get around to it ;-)
>>
>> Gary
>>
>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boards@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>> wrote:
>> This sounds like an interesting idea worth pursuing.
>>
>> On 4 July 2016 at 14:56, Gary Gregory <garydgregory@gmail.com <ma...@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 <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>>
>>
>> Mikael Ståldal
>> Senior software developer
>>
>> Magine TV
>> mikael.staldal@magine.com <ma...@magine.com>
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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 <ma...@gmail.com>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
I mean ideally, log4j should be running as a server library. Some of the
JEE servers come with log4j 2 out of the box I think.
On 14 July 2016 at 16:36, Paul Benedict <pb...@apache.org> wrote:
> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0
> thing :-) but it would be really awesome if Log4J could advertise itself as
> EE compatible with threading. Just my 2 cents. When it comes to the
> refactoring, you'll just want to have a good abstraction built so you can
> plug in the right implementation at runtime (non-container vs container).
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I’m not aware that frameworks like Log4j actually adhere to those
>> guidelines. It is too difficult to write code that works in both the JEE
>> and non-JEE environments.
>>
>> Ralph
>>
>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>
>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@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
>>>
>>
>>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j should manage it's own threads
Posted by Mikael Ståldal <mi...@magine.com>.
We should not make Log4j dependent on JavaEE. We should make sure it
continue to work in other server frameworks (Akka, ReactiveX, Finagle,
etc.) as well.
On Fri, Jul 15, 2016 at 2:06 AM, Remko Popma <re...@gmail.com> wrote:
> The purpose of the J2EE thread model is to prevent prevent custom threads
> from interacting with container threads. I believe that it is the
> intention to protect against data corruption issues, data visibility issues
> etc.
> If it was allowed for custom threads to call servlet or EJB methods
> concurrently with calls from container threads, it would be impossible to
> make thread-safe J2EE apps.
>
> What Log4j and various other libraries do is create helper threads to
> offload processing from the container threads. As long as our threads don't
> call back into the application the thread-safety risks are manageable. We
> essentially rely on people to not do crazy stuff in their toString()
> methods.
>
> As far as I am aware, any "worker thread" frameworks provided by J2EE
> containers are not designed for performance requirements like ours. They
> also don't solve any issues with objects doing crazy stuff in their
> toString() method.
>
> So practically speaking there's only drawbacks and no benefits for Log4j
> to adhere to the letter of the specification. We do adhere to the spirit of
> it though.
>
> Frankly speaking I think this part of the J2EE spec was not very well
> thought out. I think this is one of the reasons we will see reactive
> frameworks like Akka and ReactiveX take market share in spaces where J2EE
> now dominates.
>
>
> Sent from my iPhone
>
> On 2016/07/15, at 6:36, Paul Benedict <pb...@apache.org> wrote:
>
> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0
> thing :-) but it would be really awesome if Log4J could advertise itself as
> EE compatible with threading. Just my 2 cents. When it comes to the
> refactoring, you'll just want to have a good abstraction built so you can
> plug in the right implementation at runtime (non-container vs container).
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I’m not aware that frameworks like Log4j actually adhere to those
>> guidelines. It is too difficult to write code that works in both the JEE
>> and non-JEE environments.
>>
>> Ralph
>>
>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>
>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@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
>>>
>>
>>
>>
>
--
[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.
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
We have some legacy crap using Oracle Commerce at work (as a shitty CMS,
not even for eCommerce) that requires JEE, but other than that, yeah, I've
been using Spring and Camel mostly which are generally Tomcat or Jetty or
even just Netty.
On 14 July 2016 at 20:23, Ralph Goers <ra...@dslextreme.com> wrote:
> I am not even aware that J2EE/JEE dominates. The environments I have
> always worked in use Spring.
>
> Ralph
>
> On Jul 14, 2016, at 5:06 PM, Remko Popma <re...@gmail.com> wrote:
>
> The purpose of the J2EE thread model is to prevent prevent custom threads
> from interacting with container threads. I believe that it is the
> intention to protect against data corruption issues, data visibility issues
> etc.
> If it was allowed for custom threads to call servlet or EJB methods
> concurrently with calls from container threads, it would be impossible to
> make thread-safe J2EE apps.
>
> What Log4j and various other libraries do is create helper threads to
> offload processing from the container threads. As long as our threads don't
> call back into the application the thread-safety risks are manageable. We
> essentially rely on people to not do crazy stuff in their toString()
> methods.
>
> As far as I am aware, any "worker thread" frameworks provided by J2EE
> containers are not designed for performance requirements like ours. They
> also don't solve any issues with objects doing crazy stuff in their
> toString() method.
>
> So practically speaking there's only drawbacks and no benefits for Log4j
> to adhere to the letter of the specification. We do adhere to the spirit of
> it though.
>
> Frankly speaking I think this part of the J2EE spec was not very well
> thought out. I think this is one of the reasons we will see reactive
> frameworks like Akka and ReactiveX take market share in spaces where J2EE
> now dominates.
>
>
> Sent from my iPhone
>
> On 2016/07/15, at 6:36, Paul Benedict <pb...@apache.org> wrote:
>
> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0
> thing :-) but it would be really awesome if Log4J could advertise itself as
> EE compatible with threading. Just my 2 cents. When it comes to the
> refactoring, you'll just want to have a good abstraction built so you can
> plug in the right implementation at runtime (non-container vs container).
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I’m not aware that frameworks like Log4j actually adhere to those
>> guidelines. It is too difficult to write code that works in both the JEE
>> and non-JEE environments.
>>
>> Ralph
>>
>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>
>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> *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 <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@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
>>>
>>
>>
>>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j should manage it's own threads
Posted by Ralph Goers <ra...@dslextreme.com>.
I am not even aware that J2EE/JEE dominates. The environments I have always worked in use Spring.
Ralph
> On Jul 14, 2016, at 5:06 PM, Remko Popma <re...@gmail.com> wrote:
>
> The purpose of the J2EE thread model is to prevent prevent custom threads from interacting with container threads. I believe that it is the intention to protect against data corruption issues, data visibility issues etc.
> If it was allowed for custom threads to call servlet or EJB methods concurrently with calls from container threads, it would be impossible to make thread-safe J2EE apps.
>
> What Log4j and various other libraries do is create helper threads to offload processing from the container threads. As long as our threads don't call back into the application the thread-safety risks are manageable. We essentially rely on people to not do crazy stuff in their toString() methods.
>
> As far as I am aware, any "worker thread" frameworks provided by J2EE containers are not designed for performance requirements like ours. They also don't solve any issues with objects doing crazy stuff in their toString() method.
>
> So practically speaking there's only drawbacks and no benefits for Log4j to adhere to the letter of the specification. We do adhere to the spirit of it though.
>
> Frankly speaking I think this part of the J2EE spec was not very well thought out. I think this is one of the reasons we will see reactive frameworks like Akka and ReactiveX take market share in spaces where J2EE now dominates.
>
>
> Sent from my iPhone
>
> On 2016/07/15, at 6:36, Paul Benedict <pbenedict@apache.org <ma...@apache.org>> wrote:
>
>> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0 thing :-) but it would be really awesome if Log4J could advertise itself as EE compatible with threading. Just my 2 cents. When it comes to the refactoring, you'll just want to have a good abstraction built so you can plug in the right implementation at runtime (non-container vs container).
>>
>> Cheers,
>> Paul
>>
>> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> I’m not aware that frameworks like Log4j actually adhere to those guidelines. It is too difficult to write code that works in both the JEE and non-JEE environments.
>>
>> Ralph
>>
>>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pbenedict@apache.org <ma...@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.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boards@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>> wrote:
>>> This sounds like an interesting idea worth pursuing.
>>>
>>> On 4 July 2016 at 14:56, Gary Gregory <garydgregory@gmail.com <ma...@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 <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com <ma...@magine.com>
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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 <ma...@gmail.com>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
Re: Log4j should manage it's own threads
Posted by Remko Popma <re...@gmail.com>.
The purpose of the J2EE thread model is to prevent prevent custom threads from interacting with container threads. I believe that it is the intention to protect against data corruption issues, data visibility issues etc.
If it was allowed for custom threads to call servlet or EJB methods concurrently with calls from container threads, it would be impossible to make thread-safe J2EE apps.
What Log4j and various other libraries do is create helper threads to offload processing from the container threads. As long as our threads don't call back into the application the thread-safety risks are manageable. We essentially rely on people to not do crazy stuff in their toString() methods.
As far as I am aware, any "worker thread" frameworks provided by J2EE containers are not designed for performance requirements like ours. They also don't solve any issues with objects doing crazy stuff in their toString() method.
So practically speaking there's only drawbacks and no benefits for Log4j to adhere to the letter of the specification. We do adhere to the spirit of it though.
Frankly speaking I think this part of the J2EE spec was not very well thought out. I think this is one of the reasons we will see reactive frameworks like Akka and ReactiveX take market share in spaces where J2EE now dominates.
Sent from my iPhone
> On 2016/07/15, at 6:36, Paul Benedict <pb...@apache.org> wrote:
>
> Ralph, I am sure it does require some refactoring. Sounds like a good 3.0 thing :-) but it would be really awesome if Log4J could advertise itself as EE compatible with threading. Just my 2 cents. When it comes to the refactoring, you'll just want to have a good abstraction built so you can plug in the right implementation at runtime (non-container vs container).
>
> Cheers,
> Paul
>
>> On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> I’m not aware that frameworks like Log4j actually adhere to those guidelines. It is too difficult to write code that works in both the JEE and non-JEE environments.
>>
>> Ralph
>>
>>> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>>>
>>> Cheers,
>>> Paul
>>>
>>>> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>> I'll get around to it ;-)
>>>>
>>>> Gary
>>>>
>>>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>>
>>>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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
>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>> Spring Batch in Action
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> 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 <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>
Re: Log4j should manage it's own threads
Posted by Paul Benedict <pb...@apache.org>.
Ralph, I am sure it does require some refactoring. Sounds like a good 3.0
thing :-) but it would be really awesome if Log4J could advertise itself as
EE compatible with threading. Just my 2 cents. When it comes to the
refactoring, you'll just want to have a good abstraction built so you can
plug in the right implementation at runtime (non-container vs container).
Cheers,
Paul
On Thu, Jul 14, 2016 at 4:34 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I’m not aware that frameworks like Log4j actually adhere to those
> guidelines. It is too difficult to write code that works in both the JEE
> and non-JEE environments.
>
> Ralph
>
> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> I'll get around to it ;-)
>>
>> Gary
>>
>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>>>>
>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>
>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@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
>>
>
>
>
Re: Log4j should manage it's own threads
Posted by Ralph Goers <ra...@dslextreme.com>.
I’m not aware that frameworks like Log4j actually adhere to those guidelines. It is too difficult to write code that works in both the JEE and non-JEE environments.
Ralph
> On Jul 14, 2016, at 1:07 PM, Paul Benedict <pb...@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.
>
> Cheers,
> Paul
>
> On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> I'll get around to it ;-)
>
> Gary
>
> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boards@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>> wrote:
> This sounds like an interesting idea worth pursuing.
>
> On 4 July 2016 at 14:56, Gary Gregory <garydgregory@gmail.com <ma...@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 <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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 <ma...@gmail.com>>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Log4j should manage it's own threads
Posted by Paul Benedict <pb...@apache.org>.
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 <ga...@gmail.com>
wrote:
> On Thu, Jul 14, 2016 at 1:07 PM, Paul Benedict <pb...@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 <ga...@gmail.com>
>> wrote:
>>
>>> I'll get around to it ;-)
>>>
>>> Gary
>>>
>>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>>
>>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@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
>
Re: Log4j should manage it's own threads
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jul 14, 2016 at 1:07 PM, Paul Benedict <pb...@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 <ga...@gmail.com>
> wrote:
>
>> I'll get around to it ;-)
>>
>> Gary
>>
>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>>>>
>>>>>> This sounds like an interesting idea worth pursuing.
>>>>>>
>>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@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
Re: Log4j should manage it's own threads
Posted by Paul Benedict <pb...@apache.org>.
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.
Cheers,
Paul
On Thu, Jul 14, 2016 at 2:41 PM, Gary Gregory <ga...@gmail.com>
wrote:
> I'll get around to it ;-)
>
> Gary
>
> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>>>
>>>>> This sounds like an interesting idea worth pursuing.
>>>>>
>>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@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
>
Re: Log4j should manage it's own threads
Posted by Gary Gregory <ga...@gmail.com>.
I'll get around to it ;-)
Gary
On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <bo...@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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>>
>>>> This sounds like an interesting idea worth pursuing.
>>>>
>>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@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
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@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 <mi...@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 <bo...@gmail.com> wrote:
>>
>>> This sounds like an interesting idea worth pursuing.
>>>
>>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
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 <mi...@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 <bo...@gmail.com> wrote:
>
>> This sounds like an interesting idea worth pursuing.
>>
>> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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 <bo...@gmail.com>
Re: Log4j should manage it's own threads
Posted by Mikael Ståldal <mi...@magine.com>.
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 <bo...@gmail.com> wrote:
> This sounds like an interesting idea worth pursuing.
>
> On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@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.
Re: Log4j should manage it's own threads
Posted by Matt Sicker <bo...@gmail.com>.
This sounds like an interesting idea worth pursuing.
On 4 July 2016 at 14:56, Gary Gregory <ga...@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 <bo...@gmail.com>