I had not built the latest pool code from CVS in a while. But I make use of the
ResourceLimitingPool from excalibur-pool-1.2 in several projects without any
problems. It has been a very long time since I was aware of any bugs in that code
and had fixed the few that I was aware of.
As I wrote that, I checked out the latest code and did a build and found that
tests were failing.
Looking at the code of the test, I don't see how it could have ever passed reliably.
This is not the test that I originally committed. But I am not sure originally rewrote it
to use JUnitPerf as the history is gone! Nicolas looks like he tried to fix it recently.
But the fix was still highly dependent on CPU speed.
This was a bug with the test, not with the pool. But it is fixed now and should
now pass reliably.
I agree 100% with the need to be careful about wiping out the CVS history. As
a contributor. I find it very discouraging. Between that and the removal of all author
tags in the source. It feels like evidence of much of the sweat time and energy that
I have put into avalon has been removed. I do not contribute code simply for
recognition. But I do not feel it is in anyway unreasonable to expect that a record
of my work and recognition for who did that work remain in the code. I know I
lost that argument a while back when the discussion of whether or not to remove
the author tags came up. But at least then I thought there would be a record of
my work in CVS.
You look through the pool package and there is now absolutely no record that
I had ever existed. I am afraid to go look at the rest of the CVS archive... It
does not encourage me to find time in my busy schedule to continue contributing.
Cheers, Leif
Noel J. Bergman wrote:
Have just committed some changes in the excalibur thread package
linked to the updates I made to excalibur-pool
2. removed deprecated ThreadControl and ThreadPool
If Avalon's ResourceLimitingPool is finally working properly, so that we don't need the one in James, let me know. Otherwise, it sounds as if we just broke org.apache.james.util.thread.DefaultThreadPool. See: http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/uti l/thread/?only_with_tag=branch_2_1_fcs
If everything works, I could use http://cvs.apache.org/viewcvs.cgi/avalon-components/cornerstone/threads/impl /src/java/org/apache/avalon/cornerstone/blocks/threads/ResourceLimitingThrea dManager.java. However, there were bugs in the Avalon code in the past. I know that Leif did some work on parts of it back in the same timeframe when I extracted the necessary code for James to work, but I don't know if he got to all of the bugs. Unfortunately, with all of the shuffling of file locations, we've effectively lost all of the CVS history, so when I look at something like http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/ apache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there is no history *at all* to see.
If we are going to keep re-organizing code, perhaps it is time to get into Subversion, so that we stop losing the change history? If you look here: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/ apache/avalon/excalibur/thread/impl/, not one file has any change history. And don't tell me to go look in the Attic somewhere.
If I come across as a bit annoyed, actually I am. I spent a lot of time in the past to trace through the code. Now I want to go back and see if problems were fixed so that we can use the new code. But the change logs are gone, so I have to re-analyze the code from scratch. That's pretty much an incentive to use the already tested code in the James CVS, except that the interface changes mean that code is broken, too.
Am I getting my point(s) across?
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
