Request logs rolling with suffixes from Jetty

It seemed simple enough. The goal: get jetty to log requests to a file such as request.log and rotate that file on a daily basis to something with a suffix.

By default Jetty wants to rename request logs something like mm_dd_yy_request.log, this is all well and good, but it complicates the logic of any tool you might use to sync and remove log files. For example log4j's RollingFileAppender will append numeric suffixes like .1 to the end of logs it has closed and rotated out, but with Jetty's default configuration, one has to get a little tricky to figure out what request log is still open. It's not as easy as grabbing request.log.* to grab the out-of-rotation logs.

I discovered the solution in the code of RolloverFileOutputStream, the class in jetty-util that Jetty's NCSARequestLog class uses internally to write the log files. When logfile appending is turned off and RolloverFileOutputStream attempts to open a new log where a file with the same name already exists, RolloverFileOuputStream will rename the existing file by appending the date, format specified by the system property ROLLOVERFILE_BACKUP_FORMAT, to the existing logfile name. This means that the request.log is the live, open log and files named like request.log.yyyyMMdd-HHmmss are the logs that are out of rotation.

So to achieve this, modify the RequestLog entry in jetty.xml to look like this:

    <Ref id="RequestLog">
      <Set name="requestLog">
        <New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog">
          <Arg><SystemProperty name="jetty.logs" default="./logs"/>/request.log</Arg>
          <Set name="retainDays">31</Set>
          <Set name="append">false</Set>
          <Set name="extended">false</Set>
          <Set name="LogTimeZone">GMT</Set>
          <Set name="ignorePaths">
            <Array type="java.lang.String">
              <Item>/solr/ping</Item>
            </Array>
          </Set>
        </New>
      </Set>
    </Ref>

And at starup of your jetty instance, do something like:

java -DROLLOVERFILE_BACKUP_FORMAT=yyyyMMdd-HHmmss -jar start.jar

And Viola! New log messages are written to request.log and logs are rolled out to request.log.somenicesuffixhere.

As for the ignorePaths stanze in the configuration above, you probably don't need it in your configuration. It's handy for me to skip logging health checks.

Also as for syncing the logs off the individual machines they're written to, rsync's --remove-sent-files option is pretty handy.

Changing Laptop Screen Brightness from the command-line

My new Dell Studio 15's laptop screen is great. It is bright, and by bright I mean that on full brightness I can use it outside on a sunny day with my sunglasses on and still read the screen comfortably. This brightness is great except for cases when I don't want it so bright, like when I'm working in a darker room. One night I discovered that the lower third of my vision had a dark blind spot after doing some work while watching a movie. That can't be good.

Problem is, I don't always remember to adjust the brightness, and from what I can tell, it always boots into Ubuntu af full brightness, so I dug around for a way to change the brightness automatically. Thanks to google I found a post over on LinuxScrew that talks about changing the brightness for a dell inspiron 1501. Turns out the Studio 15 has a similar method using /proc. Cat'ing the file shows me the acceptable brightness levels:

# cat /proc/acpi/video/M86/LCD/brightness 
levels:  6 12 18 24 30 36 42 48 54 60 66 72 78 84 90 100
current: 100

Echo'ing something to the file (as root) sets the value:

# echo -n 18 > /proc/acpi/video/M86/LCD/brightness 

There's lots of places to go with this, but for now I'm going to pop it into rc.local and run with it.

No more blind spots, excellent.

Serving content with Solr's Jetty instance.

When prototyping with Solr 1.4.x, I've found it useful to serve webpages, javascript and images using the Jetty server used by Solr's example instance. Doing so is straightforward:

Create a directory named contexts in the Solr examples directory which contains the etc and start.jar files. Create a context definition file inside this directory. It can be named anything, I commonly call it root-context.xml

The file contains the following:

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/</Set>
  <Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/contexts/root</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>
</Configure>

In the contexts directory, create a directory named root and place your content there. Voila -- once you launch the solr instance with java -jar start.jar, everything placed in the root directory is available under http://yourhostname:8983, while solr is availble at http://yourhostname:8983/solr

A Useful Hint to Young Engineers

When I visited Thomas Edison's lab in Orange, NJ last winter, I spotted a clipping in one of the displays:

"A Useful Hint to Young Engineers -- 'The man for whom every employer of men is searching, everywhere and always is the man who will accept the responsibility for the work he has to do -- who will not lean at every point upon his superior for additional instructions, advice or encouragement.

There is no more valuable subordinate than the man to whom you can give a piece of work and then forget about it, in the confident expectation that the next time it is brought to your attention it will come in the form of a report that the thing has been done. When this master quality is joined to the executive power, loyalty and common sense, the result is a man whom you can trust. On the other hand, there is no greater nuisance to a man heavily burdened with the direction of affairs than the weak-backed assistant who is continually trying to get his chief to do his work for him, on the feeble idea that he thought the chief would like to decide this or [that]."

Gender bias aside, a useful hint indeed.

Ubuntu 9.10 and sticky java dialog boxes.

I'm running Ubuntu 9.10 in my laptop and have been suffering from an unusual problem. The buttons on dialog boxes created by the eclipse ide 'stick'. When I click on any button in a dialog, it gets stuck in the down position and never activates. The only solution is to tab over to the button if possible and activate it with the return key. Very irritating.

I finally tracked down the fix today. The problem is caused by something related to the way in which GDK renders its windows in the latest version. The solution is to set the environment variable GDK_NATIVE_WINDOWS=1 prior to launching eclipse. Apparently this is also a problem on newer versions of Fedora as well. Indeed it is probably an issue with anything running gdk 2.18 or newer, where the switch to 'client side windows' was made.

I've fixed this by renaming eclipse to eclipse.bin and placing the following script named eclipse in the same directory:

#!/bin/bash
BASE=$(dirname $0)
export GDK_NATIVE_WINDOWS=1
exec $BASE/eclipse.bin

don't forget to chmod +x it so that it is executable. You'll also have to rename eclipse.ini to eclipse.bin.ini -- eclipse finds its ini based on the binary name.

sheesh.

For an explanation of what GDK_NATIVE_WINDOWS is all about, check out the post "What GDK_NATIVE_WINDOWS=1" means over on Dax's blog.

GUID vs. Auto-Increment Primary Keys.

This all started off from reading yet another wonderful post over at Better Explained, which is currently my favorite blog of the moment. My Google reader starred items list overflows with entries to-read from this blog. I wanted to brush up on the semantics of GUIDs/UUIDs because I'm currently implementing RDF output for one of our products from work and keeping the object URIs unique and consistent is a good thing. I'm using a simple MD5 hash for that.

The interesting aspect that cem out of this is the discussion of using GUIDs as database primary keys. We'd tried that a couple years ago but abandoned the implementation for a number of reasons.

I'll come back and finish this post some day, but I really just want to capture a bunch of links in one place. It would be cool if those social bookmarking services would allow you to cluster a bunch of links together into a single posting. At any rate, I'll use a blog for this instead and see how it works.

• Coding Horror: Primary Keys: IDs versus GUIDs
• Brian "Krow" Aker's Idle Thoughts - Myths, GUID vs Autoincrement: Excellent discussion here, need to go back and find out if he ever did benchmarks for secondary keys.
• MySQL Performance Blog: To UUID or not to UUID?

The general sentiment here is is that using UUID's instead of auto-incrementing ints decentralizes id assignment, enabling scale and avoiding having to re-key data when it's merged. The tradeoffs related to space are worth it and the performance impact is likely to be minimal

Earthquake in NJ

Growing up in NJ, earthquakes were unheard of. Back when I was a kid in Bergen County I felt one. It was a Saturday morning, and I was at a friend's house after sleeping there the night before. It lasted long enough for us to realize we didn't know what was going on and to run outside of the house and witness everything moving.

I was thinking about the quake lately and finally managed to track down the event. According to the Lamont-Doherty Earth Observatory of Columbia University, the earthquake occured about 6:04am on October 19th, 1985 and was measured at 4.0 on the Richter scale. Its epicenter was in Ardsley, NY. (40.98N, 73.83W), referred to as the "Ardsley Quake".