cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: woah there - "vetoed" changes committed to Engine
Date Sun, 17 Sep 2000 04:20:07 GMT
On Sat, 16 Sep 2000, Robin Green wrote:

> Right. Sorry, I forgot about that. It's been a while since I read the 
> constitution.

no worries. just wanted to make sure you knew we had one. :)

> 1. Fixing a bug that only allowed one request through the engine at a time 
> (that's right - one thread per engine!), which was not what was intended at 
> all, according to the submitter (i.e. I removed the synchronized (this) {} 
> ). I can't see how this change can be dangerous. It's just changing it back 
> to how it was in 1.7.4. I think the original synrchronized block was just 
> left in mistakenly.
> 
> 2. Fixing a possible missed notify() by synchronizing fully on the Block 
> object, rather than only part of the time. I can't see how this change could 
> be dangerous either - indeed it prevents a bug that could have been very 
> hard to find and could have caused mysterious timeouts on many sites on 
> heavy load - when one thread unblocks before another thread is ready to 
> receive the notification. That's a synchronization ABC thing, anyway - at my 
> college it was exactly this concept of missed notify that was used to 
> explain why synchronization is necessary.
> 
> 3. A very primitive profiler that just takes the current time at various 
> points and puts the results in a hashtable, that is disabled by default in 
> cocoon.properties - so it can't do any damage. (Touch wood!)

heheheh, can't do any damage. okay, you convinced me. +1

> B. Keep them, and release on schedule, with only a few days testing period. 
> We have Apache JMeter - that's good for testing multi-threading. (note that 
> JMeter can also expose JVM bugs, not just Cocoon bugs.)

+1

> Ultimately I feel that leaving these bugs in (with admittedly 
> hard-to-quantify risks), out of a belief that the risks are higher if they 
> are fixed, is a misjudgement. If you're going to leave bugs in software, 
> there'd better be a good reason for it, which _outweighs_ the reason for 
> fixing it - and I don't think it does in this case. (Obvious point, I know, 
> but how else could I say it?)

well, known potential bugs v.s. unknown bugs from fix - it's a hard
call. you seem to have a good grasp of multithreading issues tho.

> So, for the sake of the "dignity" of the Cocoon project overall, including 
> myself, I'd like to get it in a more shipshape condition. Now you may say 
> that's about image and PR and marketing etc. which we are things we should 
> stop getting hung up about - but it's not just image, it's about code 
> quality (and quality of the docs). And yes I admit it, I am being fussy, but 
> we're all allowed our little weaknesses aren't we? :)

+1 for fussiness. +2 for improving the docs. :)

- donald


Mime
View raw message