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 <remko.po...@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 <pbened...@apache.org > <mailto:pbened...@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.go...@dslextreme.com >> <mailto:ralph.go...@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 <pbened...@apache.org >>> <mailto:pbened...@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 <garydgreg...@gmail.com >>> <mailto:garydgreg...@gmail.com>> wrote: >>> I'll get around to it ;-) >>> >>> Gary >>> >>> On Thu, Jul 14, 2016 at 11:35 AM, Matt Sicker <boa...@gmail.com >>> <mailto:boa...@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 <boa...@gmail.com >>> <mailto:boa...@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.stal...@magine.com >>> <mailto:mikael.stal...@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 <boa...@gmail.com >>> <mailto:boa...@gmail.com>> wrote: >>> This sounds like an interesting idea worth pursuing. >>> >>> On 4 July 2016 at 14:56, Gary Gregory <garydgreg...@gmail.com >>> <mailto:garydgreg...@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: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>> ggreg...@apache.org <mailto:ggreg...@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 <boa...@gmail.com <mailto:boa...@gmail.com>> >>> >>> >>> >>> -- >>> >>> >>> Mikael Ståldal >>> Senior software developer >>> >>> Magine TV >>> mikael.stal...@magine.com <mailto:mikael.stal...@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 <boa...@gmail.com <mailto:boa...@gmail.com>> >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>> ggreg...@apache.org <mailto:ggreg...@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> >> >>
