logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Log4j 1.3 Woes
Date Tue, 29 Nov 2005 03:16:13 GMT
Curt Arnold wrote:

> There were two fairly long threads this summer on the topics raised  
> in this thread (http://marc.theaimsgroup.com/?l=log4j- 
> dev&m=111901190409097&w=2 and http://marc.theaimsgroup.com/? 
> t=112094138900003&r=1&w=2).  I haven't seen any new issues here, just  
> a reiteration that we are not in a happy place at the moment.

I'll have to review those threads...

> Basically, 1.2 and 1.3 are not binary (aka classfile) or  
> serialization compatible at the moment.  It is definitely possible  
> you will get a class loader exception if you run code compiled  
> against 1.2 with a log4j 1.3 jar.  The breaking of binary  
> compatibility occurred before most of the current developers became  
> involved and we are trying to restore binary compatibility, but  
> obviously would have liked to have made more progress.  One of the  
> reasons that we are still calling 1.3 an alpha is we want to change  
> that which will likely break some code that was compiled against  
> earlier log4j 1.3 alphas.

That all makes good sense.  I do believe that

   1. some statement to this effect on the log4j site,
   2. a request for help in identifying and addressing such issues,
   3. some determination as to the validity of the recipes for preparing
      code for 1.3, and
   4. near-term efforts to resolve issues and/or the recipes so that
      good advice can be given

are all necessary as soon as possible.  In particular, while not using 
Category or Priority directly sound well and good it seems quite 
uncertain that that will actually buy anyone anything substantive in the 
end.

> Resolving the "deadlock issue" (bug 24259 and 33855) in my opinion  
> will require breaking the existing threading contract which will  
> likely cause applications that depend on the current behavior to  break.

Understood.

> As such, I do not think that there is a possible fix except  in the 
> forthcoming 2.0 branch (which would not be constrained to  binary 
> compatibility) and then it may require a bit of  experimentation to 
> find the right tack.

That seems *way* too far off given that 1.3's release timeframe itself 
is still quite hazy.  If this cannot be resolved in any definitive near 
term then I guess it is time to start my converting to JULI now...

I understand and accept that this will break some applications, but 1.3 
seems like a fine time and place to do this -- assuming 1.3 releases 
some time in the next 6 months.

> My personal preference would  be to rework a lot of the formatting and 
> dispatching code to be more  verifiably thread safe and use finer 
> grain locking than what we  currently have, but as a project we can't 
> make those types of  decisions until we see some code.  The issue is 
> not a regression,  just a downside of the threading strategy that has 
> been in log4j for  a long time.

Understood, but a timeframe for addressing the issue -- without 
unnecessarily introducing other compatibility issues -- is still necessary.

> It may be possible to improve the locking behavior for a particular  
> application in a branch of either 1.2 or 1.3 (at the potential  
> expense of breaking or changing the performance of other apps), but I  
> don't think we can offer a general purpose improvement in the 1.x  
> releases. 

I think we must in 1.3.

On the other hand, I've not seen the deadlock in my application yet, so 
it may never hit it.  The specter of such an issue cannot be accepted 
for long, however.

--
Jess Holle


Mime
View raw message