logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: Scheduler
Date Wed, 21 May 2014 16:59:25 GMT
As I am sure many of you already know, you don't want to create threads in
a container. You want to let the application server manage that. So I think
you guys should seriously consider supporting standard Java EE solutions
for those who are going to use this stuff in application servers.


Cheers,
Paul


On Wed, May 21, 2014 at 11:56 AM, Matt Sicker <boards@gmail.com> wrote:

> So couldn't you just use java.util.Timer with java.util.TimerTask? Or are
> you thinking more along the lines of Executors.newScheduledThreadPool?
>
>
> On 21 May 2014 11:51, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>
>> I definitely don’t want to be dependent on JEE for a timer service.
>>
>> Ralph
>>
>>
>> On May 21, 2014, at 9:40 AM, Paul Benedict <pbenedict@apache.org> wrote:
>>
>> You may want to provide a standard Java EE solution using the Timer
>> service:
>> http://docs.oracle.com/javaee/6/tutorial/doc/bnboy.html
>>
>>
>> Cheers,
>> Paul
>>
>>
>> On Wed, May 21, 2014 at 11:33 AM, Gary Gregory <garydgregory@gmail.com>wrote:
>>
>>> We embed Quartz at work for scheduling. Instead of inventing our own,
>>> perhaps we could make this pluggable with a really "simple" default that is
>>> our own.
>>>
>>> Surely there are already other schedulers in the Apache lands.
>>>
>>> Gary
>>>
>>>
>>> On Wed, May 21, 2014 at 11:31 AM, Remko Popma <remko.popma@gmail.com>wrote:
>>>
>>>> I can see how that would solve one or more issues that keep coming up
>>>> with the RollingAppender.
>>>> I hope that it may also make it easier to break down the rollover logic
>>>> into smaller pieces that can be unit tested easier, something that I've
>>>> been meaning to work on.
>>>>
>>>> The only drawback (if this even is a drawback) I can think of is that
>>>> we would always be running a background thread. At the moment Log4J only
>>>> starts a background thread when Async Loggers are used, or potentially
>>>> multiple threads for every AsyncAppender that is configured.
>>>>
>>>> Perhaps we can start by creating the thread unconditionally and later
>>>> enhance to only create/start the Executor if necessary: when a
>>>> RollingAppender or a monitoringInterval is configured.
>>>>
>>>> I can't think of anything else, sounds like a good idea to me.
>>>>
>>>>
>>>>
>>>> On Wed, May 21, 2014 at 11:52 PM, Ralph Goers <
>>>> ralph.goers@dslextreme.com> wrote:
>>>>
>>>>> I am thinking that I am going to add a Scheduler class. It will expose
>>>>> a schedule method that accepts a Runnable as a parameter along with the
>>>>> initial time and frequency.  The schedule method would schedule a Timer
>>>>> Task that passes the Runnable to an Executor when the time expires.
>>>>>
>>>>> I would then use this service to check for configuration changes and
>>>>> file rollovers instead of the way it is currently done, which requires
log
>>>>> events to trigger them.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Ralph
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>

Mime
View raw message