felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Deadlock in Felix
Date Mon, 11 Feb 2008 08:29:17 GMT

Am Montag, den 11.02.2008, 09:17 +0100 schrieb Karl Pauls:
> > Later on, I think I'll change Pax Logging to move all incoming requests (log
> > and config) to its own thread to prevent the whole issue all together.
> Good - so we don't have to hurry. However, do you (and others) think
> it is acceptable to deliver log events asynchronously or at least
> later then the actual point they occur? We have the eventdispatching
> thread around anyways and I think it should be doable to use it to
> deliver events. But I will only spend time looking into this if the
> general opinion is that it is worthwhile ...

I am not sure, whether this would be a good solution, because you would
then have log messages from the application and log messages from the
framework being out of think with regard to actuall order of processing.
This could cause some headaches when trying to interpret the log files.

In addition, I tend to think, that the way Log4J locks itself and by
loading classes inside that lock potentially the complete system is kind
of problematic. Not sure how NLog4J and Logback act in this respect.

On the Felix side, we might come up with a solution where we may
actively delay logging when inside some synchronized/locked code.
Probably the only really problematic location for logging is inside the
ClassLoader support. Could we gather messages there to be logged after
releasing any locks ?


View raw message