Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D985E11D21 for ; Wed, 21 May 2014 16:59:50 +0000 (UTC) Received: (qmail 86467 invoked by uid 500); 21 May 2014 16:59:50 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 86409 invoked by uid 500); 21 May 2014 16:59:50 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 86401 invoked by uid 99); 21 May 2014 16:59:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2014 16:59:50 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paulus.benedictus@gmail.com designates 209.85.192.50 as permitted sender) Received: from [209.85.192.50] (HELO mail-qg0-f50.google.com) (209.85.192.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2014 16:59:47 +0000 Received: by mail-qg0-f50.google.com with SMTP id z60so3620992qgd.37 for ; Wed, 21 May 2014 09:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HvEapae7Nyej0dsXeENH3pZSxs6ezgT+v0sQvIRxo4Y=; b=RAN4fECAgYikOuQEZ1pgBbZjLY4Yxb7EJrdsYGC4K8VPg2CBCfniBvqqSzjMRY6Jnn vN5Lj8+zuuVBlsQqheFOkxQrq9ahPMozVMbercw3u2AmerdkWTVv3bkZA82xqRxbZENQ x9ybSM23I3Lrpk6dHE+6JqMzpJViH2WOJ1Uf4/4qhrXaw5lwpao+jPtFNGBbFCO/AeLP 0aN0jcCewZ3EUFH1M1WGtZyOhPPd3XFXFIvNy3NQfDt3Q4uKMsmYxjGe4Vymg3PCEPzN dLYJiOjnL4XBeIzhOZX9TbNXGzYghAqwim6KsyFUUGRyNKnXLqZOpWWNsNNzkpG68u8W vyrA== MIME-Version: 1.0 X-Received: by 10.224.97.69 with SMTP id k5mr70796328qan.8.1400691566097; Wed, 21 May 2014 09:59:26 -0700 (PDT) Sender: paulus.benedictus@gmail.com Received: by 10.96.21.228 with HTTP; Wed, 21 May 2014 09:59:25 -0700 (PDT) In-Reply-To: References: <5E9CB183-102B-46CC-B92E-D52D1F4EEB19@dslextreme.com> Date: Wed, 21 May 2014 11:59:25 -0500 X-Google-Sender-Auth: 92hRST0gBurRSgM9u7YZD66tw2E Message-ID: Subject: Re: Scheduler From: Paul Benedict To: Log4J Developers List Content-Type: multipart/alternative; boundary=001a1133d4e63cb95e04f9ebeb12 X-Virus-Checked: Checked by ClamAV on apache.org --001a1133d4e63cb95e04f9ebeb12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 wrote: > >> I definitely don=E2=80=99t want to be dependent on JEE for a timer servi= ce. >> >> Ralph >> >> >> On May 21, 2014, at 9:40 AM, Paul Benedict 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 w= rote: >> >>> We embed Quartz at work for scheduling. Instead of inventing our own, >>> perhaps we could make this pluggable with a really "simple" default tha= t 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 wr= ote: >>> >>>> 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 logi= c >>>> into smaller pieces that can be unit tested easier, something that I'v= e >>>> 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 on= ly >>>> 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 expos= e >>>>> a schedule method that accepts a Runnable as a parameter along with t= he >>>>> initial time and frequency. The schedule method would schedule a Tim= er >>>>> 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 require= s 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 >>> 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 > --001a1133d4e63cb95e04f9ebeb12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 ma= nage that. So I think you guys should seriously consider supporting standar= d Java EE solutions for those who are going to use this stuff in applicatio= n servers.

Cheers,
Paul


On Wed, May 21, 2014 at 11:56 AM, Matt S= icker <boards@gmail.com> wrote:
So couldn't you just use java.util.Timer with java.uti= l.TimerTask? Or are you thinking more along the lines of Executors.newSched= uledThreadPool?


On 21 May 2014 11:51, Ralph Goers <ralph.goers@dslextreme.com= > wrote:
I definitely don=E2=80=99t want to be d= ependent on JEE for a timer service.

=
Ralph<= div>


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 G= regory <garydgregory@gmail.com> wrote:
We embed Quartz at work for scheduling. Instead of in= venting our own, perhaps we could make this pluggable with a really "s= imple" 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 so= lve 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 th= ink of is that we would always be running a background thread. At the momen= t Log4J only starts a background thread when Async Loggers are used, or pot= entially multiple threads for every AsyncAppender that is configured.

Perhaps we can start by creating the thread uncondition= ally and later enhance to only create/start the Executor if necessary: when= a RollingAppender or a=C2=A0monitoringInterval=C2=A0is configured.

I can't think of anything else, sounds like a good idea to m= e.



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 Sched= uler class. It will expose a schedule method that accepts a Runnable as a p= arameter along with the initial time and frequency. =C2=A0The schedule meth= od 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 r= ollovers 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




--
<= div dir=3D"ltr">E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persisten= ce with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Act= ion
Blog: http:= //garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory=





=
--
Matt Sicker <boards@gmail.com>
--001a1133d4e63cb95e04f9ebeb12--