logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Log4j should manage it's own threads
Date Fri, 15 Jul 2016 00:06:04 GMT
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> 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> 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> 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>
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
>>>>>>>>> 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 <boards@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 <boards@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Matt Sicker <boards@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
> 

Mime
View raw message