logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Log4j should manage it's own threads
Date Fri, 15 Jul 2016 00:13:37 GMT
I was thinking more along the lines of users installing it themselves. If I
were running more than one webapp in my Tomcat instance, I'd just put it in
$CATALINA_HOME/lib. Providing an easy way to upgrade is also useful.

I could have sworn one of the JEE servers came with log4j2 nowadays, but I
can't figure out which one (if any). I thought maybe Wildfly or Weblogic
were, but I can't find any documentation backing that up.

On 14 July 2016 at 18:57, Ralph Goers <ralph.goers@dslextreme.com> wrote:

> Actually, I either wish they wouldn’t or do it in such a way that it
> doesn’t impact the application’s classpath. Many applications will want to
> use newer versions that whatever version the container ships with.
>
> Ralph
>
> On Jul 14, 2016, at 4:44 PM, Matt Sicker <boards@gmail.com> wrote:
>
> I mean ideally, log4j should be running as a server library. Some of the
> JEE servers come with log4j 2 out of the box I think.
>
> On 14 July 2016 at 16: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
>>>>>>>>> <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>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *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
>>>> <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>
>
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message