Answers by Kohsuke Kawaguchi, Senior Architect at CloudBees.
A. You can launch slave via Java Web Start. This is one of the ways you can create a slave-initiated Hudson cluster. Once you launch a slave in this way, you can either install this slave as a Windows service from the GUI, or you can run "java -jar slave.jar -jnlpUrl http://.../slave-agent.jnlp" from your script to automate this. I'm curious what your problem was with the swarm plugin, though, as it's designed for this kind of usage.
A. No, unfortunately no. A decision was made a few years ago to drop 1.4 support, so that we can develop Hudson faster. Note that you need Java 5 just to run Hudson slaves, and you can continue to use Java 1.4 to build your software. I'm personally not aware of any platforms where the vendor provided Java 1.4 implementation but not 5.
A. There's no real hard limit, and many installations run 100+ slaves on a single cluster. What seems to happen beyond the certain size is that for organizational reasons people start to prefer splitting a large cluster into smaller ones, so that everyone can control their own installation freely.
A. There appears to be some stability problem in the remoting protocol currently that's affecting some users. I've been trying to reproduce and fix the problem, but so far I've been unable to reproduce the issue. Any help on this issue greatly appreciated.
A. It uses the consistent hash algorithm, which is the same algorithm the session-aware HTTP load balancer uses. The algorithm itself scales very well, and is highly efficient. It also has a number of nice characteristics, such as locality, even loading, etc.
A. Yes. There's an EC2 plugin that lets you Amazon EC2 as a on-demand slave pool. This is built on top of an extension point, so a similar implementation is possible for other backends, such as Azure, Rackspace, etc. Jenkins Enterprise by CloudBees offers a similar feature on top of your own VMWare vCenter/ESXi. Perhaps the most comprehensive option to run Hudson in the cloud is our DEV@cloud.
A. I'd love to do that if there's enough interest! Please send us your thoughts -- info@cloudbees.com -- with suggested topics we should talk about in the future.
A. Hudson assigns a directory to each build (called "workspace"), in a file system accessible to the build machine that's carrying out the build. Typically the workspace is assigned per project basis, but this can change for example if you allow concurrent builds to take place for one project (so that each concurrent build gets its own unique workspace.)
A. The only drawback to using DCOM is that it's harder to diagnose problems, when it's not working. When things fail, Windows APIs generally just report an useless error code, and you are left on your own to guess where things are wrong. On the other hand, installing SSH daemon on Windows is tedious, if not difficult. So that's the trade off you should think about.
A. As you can see in the post on Hudson Labs we've started delivering updates and plugins through mirrors around the world. The number of mirrors are increasing, and I think we have 4 to 5 now. If you'd be willing to be a mirror, please contact us.