Hi Remko & Matt, Thank you for chiming in.
As of now, the threads still exist and are not cleanly stoppable. The only way to cleanly and _simply_ stop a thread is with a flag as the patch does. >From a design stand point it does not smell right to start threads and not offer a clean way to stop them. So that's one point I see in favor of _at least_ having the new cleaner clocks in master. Whether or not we stop them automatically is another issue. I see your point about web apps but that only means (to me) that out web integration needs to override the clock factory with one that does not use a thread. If the user configures a thread based clock anyway, then what? He or she is hosed? That does not sound right. So from a process POV, I would like to: (1) Agree on how to stop a thread-based clock (my patch minus the call from the web code). (2) Discuss on who should do the stopping, if any one. At worse, the use can call the stop() method. At least we would have something in 2.1... Thoughts? Gary On Wed, Sep 10, 2014 at 7:46 PM, Remko Popma <[email protected]> wrote: > I've thought about it some more and now I'm leaning towards not fixing > this. Starting and stopping this thread brings too much complexity; it's > just not worth it. These clocks were designed to be used in ultralow (sub- > microsecond) latency applications. > Web apps don't fall into that category. > Web apps should just use the default system clock. Using any other class > gives them no benefits and only trouble. > I will update the site docs to that effect. > > > On Thursday, September 11, 2014, Matt Sicker <[email protected]> wrote: > >> Should Clock extend LifeCycle? >> >> >> On 10 September 2014 18:30, Remko Popma <[email protected]> wrote: >> >>> Gary, >>> Thanks for looking at this! >>> >>> I had a look at the patch. Some feedback: >>> * Good idea to have a Clock.stop() method >>> * As you indicated, it may be a good idea to call >>> ClockFactory.getClock().stop() in the loggerContext stop() method. That >>> way non-webapps can benefit too. >>> * We may need a Clock.start() method in loggerContext.start() then when >>> a webapp is reloaded. - but newContext.start() may get called before >>> oldContext.stop()! Need a refCount mechanism?? >>> * An alternative to creating a new class StopFlagThread is to call >>> thread.interrupt() in the stop() method, and check if interrupted() returns >>> true in the while loop: while (!interrupted()). But creating a new class >>> works just as well. >>> >>> Tiny detail: there is a log file log4j-core/LOG4J2-807.log in the >>> patch. >>> >>> >>> >>> >>> >>> On Wed, Sep 10, 2014 at 11:09 PM, Gary Gregory <[email protected]> >>> wrote: >>> >>>> Hi All: >>>> >>>> I am looking for feedback on my patch in >>>> https://issues.apache.org/jira/browse/LOG4J2-819 >>>> >>>> Thank you , >>>> Gary >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> 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 <[email protected]> >> > -- E-Mail: [email protected] | [email protected] 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
