Race condition (?) with jetty-runner

I've been using Jetty (via jetty-runner) (7.0pre5) for a few months now, generally without any issues at all (outside the bugs in my own code of course).  However, starting yesterday, I began having intermittent difficulties with starting the server, and this morning it basically stopped working completely. Specifically, the server failed to find my application from the "--path" option I was passing it (well, it *usually* failed - every now and then it'd work fine), and if I gave it paths directly to my application components it would complain about missing .jsp files (that aren't actually missing).

So I of course assumed that I had managed to break my web.xml file, but I could find no recent changes at all. I decided to try a different machine, and a clean build of my app on that machine also failed. I tried syncing back to an older revision of the code, and that failed too.

I decided to strace the server process to see if I could tell what was going wrong and leading it to give me "File not found" errors. When I ran jetty-runner via "strace", however, to my extreme surprise my application came up and worked just fine. I went back to my other development machine and tried the same trick, and sure enough running it with "strace -f " made it work like it had been working just a couple days beforehand.

With a little more poking, I caught an error reported to stdout right after an "INFO" log message:

2009-02-25 09:50:49.694::INFO:  Started SelectChannelConnector@0.0.0.0:8080

The error was that it couldn't bind to the port because something else was listening. Well, I'm a cautious person but I've been launching this with the same script for months now and it has never had that issue. There isn't anything else on port 8080 on my machine, I'm sure of it.  I kill the Jetty process and check with "netstat -ln" to make sure that 8080 is free, then I run the script. The script also makes sure no old jetty processes are running, and then just launches it.

Both the machines that exhibited this problem are dual-core machines. I'm wondering whether it's possible that under some circumstances two threads try to bind to port 8080 and one (of course) fails.