Leo Simons wrote a great summary of the last year of Gump development on the gump mailing list, which I will re-post here for those not subscribed:

08 Jun 2004: Java Gump is officially retired

17 Jun 2004: Adam announces “CleanUp” branch which becomes a big rewrite

25 Jun 2004: Open source Wing IDE licenses help productivity

25 Jun 2004 (busy day): Gump starts using JDK 1.5

08 Jul 2004: We almost move to a java implementation…

12 Jul 2004: …instead efforts start to make the code more readable

22 Jul 2004: Lots of people start throwing out “wild ideas”

24 Jul 2004: Stefano starts digging into gump

10 Aug 2004: Gump starts reaching out to the “free java” community

30 Aug 2004: First signs of gump falling over under development pressure

01 Sep 2004: Gump (sorta) gets NAnt support

02 Oct 2004: Stefano starts dynagump…

03 Oct 2004: …starts talking about software architecture…

07 Oct 2004: …tries to get the tree into a stable state…

19 Oct 2004: …doing “manual nags” aka human-assisted-gump

31 Oct 2004: Kaffe’s Dalibor Topic gets involved, we start using kaffe

26 Nov 2004: gump starts building APR and soon after HTTPD

30 Nov 2004: …Stefano gets sick of the nagging, we almost turn it off

06 Dec 2004: Gump 3.0 is proposed after being discussed at ApacheCon

28 Dec 2004: Leo starts what will eventually become the “Gump3″ branch

26 Feb 2005: Leo presents gump to the “free java” community at Fosdem

06 Apr 2005: Adam gets to work on “Gump3″ branch

I figured I’d keep the amount of stuff from 2005 that I link to a little
limited as its hard to tell right now what will be the important bits,
actually its like that for most of the past year, esp. as I’ve been more
actively involved with gump recently. That’s probably why the list is also
longer than the previous one relative to the period covered, but its also
longer because we’ve been generating more traffic and more wild ideas
recently. Hey, there might be some connection between the amount of heresy
and the scope of my involvement, who would’ve thought that

FYI, there’s some mailing list statistics at
http://people.apache.org/~coar/mlists.html#gump.apache.org
And community statistics at
http://nagoya.apache.org/~stefano/
(bound to be moved somewhere else sometime soon)

Considering the limited number of people on this list, we produce a whole
lot of e-mail

Oh, and a disclaimer might be in order as well. I didn’t apply any kind of
procedure in generating these lists. Basically I strolled through the
archive and clicked on stuff I found interesting (based on subject line or
the size of the thread or how much output the solaris installer was
generating at some point in time) and linked to it if I thought others might
find it interesting. That means there’s a whole bunch of very important
stuff that’s happened not in those lists at all (for example because I found
it kinda boring or very much without controversy).
Don’t take it personally

Oh and finally let’s not forget:

18 Jul 2005: gump developers churn out massive amounts of brilliant code
during ApacheCon Europe hackathon

Popularity: 18%

Charles Miller writes in Fun with JBoss Performance:

JBoss ships by default with logging turned up to DEBUG level. Either by design, or just as a side-effect of JBoss’s clever classloading arrangement, this configuration infects any application deployed in the server.
…
Across thousands of JBoss deployments, trillions of CPU cycles are being wasted generating strings that nobody cares about, and that might never see the light of day.
I suspect this is how JBoss Inc. consultants make their money. They can just go in, add one line to log4j.xml, demonstrate they’ve tuned the server to achieve ten times the throughput, and spend the rest of the day drinking coffee and looking smug.

I know that’s how I used to make the money in the JBoss consulting biz (Hint: I’ve never made money from JBoss consulting)

Shipping with the server defaulting to DEBUG is a sad oversight on the part of developers who have little understanding from a sysadmin perspective. Perhaps ship with 2 lines in the README on how to turn up the logging IF you have a problem. The big issue here is that most JBoss installs are used as-is, with little to no configuration. The ones that do get configuration changes, it is usually to get an application to work, not to optimize it.

If anyone needs some java application running on JBoss, or any other container for that matter, to run much faster than it currently, I am available for hire. I usually average a 50% increase in performance off of just the low-hanging fruit, and have gone as far as 20x performance improvement in non-trivial webapps, when allowed to go under the covers, so to speak.

I remember getting a mobile content delivery system from 20 requests per second up to 1680 requests per second on Weblogic back in 2000. Our application was actually faster than the default ‘Hello World’ servlet that Weblogic shipped, and we sent 10 times more content per request. Our company ended up being invited to speak at the BEA users conference, because even they could not believe that you could make something that fast.

On another occasion, in another job, I was able to move a very complex web application architecture from .7 requests per second to over 10, in about 3 days of work. With another few weeks, we had it up to 40 requests/second. That was an easy job, because everything was done in XML (from the native XML database all the way to the XSLT rendering). We still used XSLT in the end, although for a job better suited for the task.

Popularity: 20%

This is a mental bookmark post. To edit the path for man, you need to edit /etc/man.config (Linux), /etc/manpath.config (FreeBSD or OS X).

Popularity: 22%

Overheard on the mod_python mailing list, and I thought it would help if it was documented somewhere a little more friendly. On April 23, Graham Dumpleton posted to the mailing list with a solution (source):

There has been a few times on the list where questions have been asked about
how to pass information through a “req.internal_redirect()” call. The problem
is that any data which is stashed in the “req” object isn’t available to the
target of the internal redirect because Apache/mod_python constructs a new
“req” object for the subsequent handler invocation.

Turns out there is actually a way of passing at least some information. This
is done by adding new key/values to the “req.subprocess_env” table. This table
is held within Apache data structures associated with the request and contents
of it are propagated through to the target of the internal redirect. The only
trick is that the key names get modified when the redirect occurs. You also
can only store string values….

I had originally thought that you just just access the req.prev object to get any variables that you would need, and Nicholas Lehuen beat me to the punch on suggesting it. Apparently though, that does not work for any python related variable additions to the request object, ie req.someVarNotInApache = session. Grisha piped in and said that req.notes might be a more appropriate place. Graham couldn’t get it to work until he tried to use req.prev.notes.

I wonder what it would take to make python bound variables survive on the req.prev object?

Popularity: 17%