Tomcat and concurrent access to unsynchronised data

If I feel sufficiently motivated at some point to actually fix this bug, I'll chase it through the relevant mailing list. At present, I'm just recording the problem for posterity.

• Tomcat wraps servlets in StandardWrapper


• Tomcat has a single HttpConnector which accepts connections and hands them off to one HttpProcessor instance each; the processor will return itself to the available pool once the connection is terminated.


• HttpProcessor instances allocate servlets to themselves for the duration of a request (which may be the entire duration of a connection, or a connection may have many requests) and then deallocates them when finished.


• There is a lot of special-casing for SingleThreadMode (STM) servlets which cannot be allocated to more than one HttpProcessor at a time.


• This is controlled, in part, with a private field on StandardWrapper called countAllocated.


• Ingeneously (or not...) updates to countAllocated are not synchronised and, it appears, are trampling each other (from using jdb to watch changes to countAllocated):
  

  Field (org.apache.catalina.core.StandardWrapper.countAllocated) is
  1, will be 1: thread="HttpProcessor[8180][2]", org.apache.catalina
  .core.StandardWrapper.allocate(), line=669, bci=138

  
  The nearest relevant source line in StandardWrapper is:
  

  countAllocated++;



• My hypothesis is that this can only choke if two threads are trying to alter the value concurrently; in this case two are trying to set it to 1 when the nett result should be 2 (whether the conflicting operation is an increment from 0 to 1 or a decrement from 2 to 1, the addition of the failed increment should still be 2, not 1, thus the odd message from jdb).


• This in itself would not ordinarily be a concern when not using STM (and in fact there is synchronised pool management for STM), BUT, in the orderly shutdown process, StandardWrapper.unload() waits until a servlet is no longer allocated (calculated by determining whether countAllocated is zero) which is intermittently not occuring (presumably because in some cases, more decrements than increments are lost) and consequently tomcat is wedging half shut down.

The unpleasant conclusion is that, short of maintaining a custom tomcat build, it is neccessary to have a wrapper script revert to "kill -9" when orderly shutdown fails.

Bovine Philosophy

I have just stumbled across Mr. Palm Guru's Uncyclopaedia and in particular You have two cows - Uncyclopedia. This is one of the more coherent fixed-viewpoint presentations of various philosophies that I have encountered, which is of course why the article has been categorised as "Coherent" and also "Sensible Jokes". I'm considering the MC Hammer 404 page for my own web server.

Downloadable media and distribution efficiencies

One of the big conflicts of interest in the development of the Internet as a medium for public communication is that much of publishing (the promotion of works written for public viewing/reading/listening/etc. (I really don't like the term "consumption" here)) is locked to the distribution of physical media. Occasionally counter-examples arise:

• The extraordinary success of Napster and its ilk has been enough to encourage even the world's largest recording companies to engage in the "sale" of downloadable music.
• Amazon has used related ideas (an enormous archive of works for distribution stored as bits and printed upon demand) to allow it to be the place to buy most book titles (not most books; the tiny fraction of the published titles that the world's bookstores carry account for far more sales than Amazon makes, but Amazon sells more titles, far more in fact, than anybody else), but still provide a physical-media interface to customers that so delights publishing organisations.
• Also related, Brewster Kahle's Internet Bookmobile travels with digital copies of freely distributable works and prints physical copies on demand - at an astonishingly low cost - and then gives them away.
  

I don't (and didn't upon discovery) find any of the above to be terribly suprising - the Bookmobile's very low printing cost notwithstanding - they all appear to be pretty obvious consequences of the move to digital.

Here, however, is an example that I had not anticipated. It appears that audio books are relatively expensive and often bulky, so much so that the combination of the downloadable form of an audiobook and an iPod Shuffle is both cheaper and more compact than the cassettes/CDs that a library would usually handle, so, New York's Long Island Public Library has started buying downloads and iPod shuffles for new acquisitions.

Assuming that video libraries don't simply become extinct over the next decade, are we likely to see something similar for movie rentals?

JSTL and empty

I am not the first to notice this, but, what were they on when they wrote this spec? For future reference, when using JSTL 1.0 and wishing to check for emptiness of a collection, don't use

test="${empty foo}"

, use

test="${foo['empty']}"

. Of course the second form only works for Collections, the first form must still be used for arrays and Strings. The joys of design-by-committee...