felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Deadlock in Felix
Date Mon, 11 Feb 2008 08:55:29 GMT
On Feb 11, 2008 9:29 AM, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi,
> 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 ?

Sure, we could do that. Let's see whether there are other opinions
else I'll give it a shot.



> Regards
> Felix

Karl Pauls

View raw message