Hello Community,
as reported on Hudson-users mailing list (mail from 06/17/09 4:35pm and
confirmed by one other party (Jorg Heymans) shortly after:

at our organization we operate a Hudson (currently 1.310) on Linux. It is used
mostly for Maven2 Jobs using the SVN SCM.
Recently we encountered a bug that resulted in Hudson hammering the SVN server
with OPTIONS requests at a 10ms rate. (This was with Hudson 1.309)
The only way we could stop that was by terminating Hudson, deactivating the Job
that caused it did not help.

These are the requests in question:
[16/Jun/2009:16:54:10 +0200] 10.147.32.71 SSLv3 RC4-MD5 "OPTIONS
/path/in/question/trunk HTTP/1.1" 496
(repeating forever until disk full with ~10-20ms rate)

I've done some debugging and found out the following:

• When Hudson has valid credentials for a SVN site, everything works, some
  PROPGETs and so on, but nothing bad happens.
• When Hudson does not have credentials (e.g. if you create a new job) the
  request above occurs every second to every other second, whilst on preferences page.
• When Hudson does not have credentials or loses its credentials (e.g. the
  existing credential gets invalidated or the process of saving credentials in
  Hudson fails - we had both ways, the first caused on purpose to verify the
  problem, the second was the one that probably caused our issues) and a job
  starts its SCM poll to see if there's an update, these requests stated above
  start occurring at the rate stated above. They stop occurring when the access
  gets restored. Even if the job is deactivated, they will still occur.
• It seems that requests started by different SCM polls may accumulate, so that
  you'ld have multiple zombie OPTIONS-requests after some SCM polls.

These endless requesting I'ld regard as a Bug - maybe some of you could give
their opinion. A decent way to handle blocked SCMs might bei

• try it for ~10 requests and then mark the job as "prerequisite disfunct",
  stopping its scm polls and new builds.

It would be very nice if this could be stopped, since it almost crashed our
central repository server with its request (the disk that got filled with
Access/Error Logs was detected early enough so a data loss due to a real crash
was avoided).