Submitted by kohsuke on Thu, 2013-09-05 07:55
This is a guest post by Aske Olsson
Extreme feedback is an incredibly powerful way to drive quality and accelerate your developer fast feedback loop.
Having eXtreme Feedback Devices (XFDs) hooked up to your Jenkins jobs gives everyone on your team instant insight into the current software state. At customer after customer we've seen extreme feedback devices drive significant incremental productivity gains, so about a year ago we started talking about taking the concept mainstream and making it easily available to any development team. So, as a small side-project, we've decided to scratch our own itch and developed an easy-to-deploy, Linux-based, laser-cut, extreme feedback device, specifically designed for Jenkins. It infers a feeling of urgency when the build is broken, and a better sense of a achievement once the problem is fixed. Just connect the XFD to your network, install the "extreme feedback plugin" on your Jenkins server and configure which jobs to feedback extremely.
Seize the opportunity to join the Jenkins community!
Just like last year, the Scandinavian Jenkins Conference will be in Copenhagen, Denmark, hosted by Praqma and sponsored by CloudBees, Sony, Switch::Gears, and PRQA. The open source community will gather on September 6th for a full day of networking and knowledge sharing at The Department of Computer Science at The University of Copenhagen.
Based on last year's success, Jenkins developers, architects, business managers, etc. from all over the world will gather to exchange experiences and promote the open source platform. As a special feature the conference will include an opening keynote from Jenkins founder Kohsuke Kawaguchi as well as other industry pioneers, who will take the podium to present findings within the latest technology, best practice, hand-on experiences, etc.
To get updates on the conference follow the JCI13Blog where you can view the latest news on venue and speakers.
As the usage of Jenkins expands, we started seeing users who run multiple 100s of slaves on one master, and thus it became a lot more important for us to scale well to even larger number of slaves.
While I was looking at the thread dump of a large system, I started noticing that there are a large number of threads lying around pumping InputStream and writing to another OutputStream. On Linux, each thread occupies 2MB just for its stack size, so if we can eliminate some of them, it'd be a good saving.
So this morning, I tackled one source of such waste.
Jenkins has the ability to launch slave on a remote server via SSH for the longest time, and to simplify this, we've been using a pure-Java implementation of SSH client.
To cut the long story short, I was able to eliminate two pump threads per every SSH connection. Furthermore, when it runs on the upcoming Jenkins 1.521, it'll save one more thread per every SSH connection. So if you have 100 slaves connected through SSH, this alone saves up 600MB of memory. That's pretty good for a few hours work!
Your favorite Butler will visit Israel on June 6 for the Jenkins User Conference Israel. More than 200 people have already registered to hobnob with other Jenkins users and eat like kings.
The agenda is up here. You’ll find a great list of speakers from Israel, Europe and the US to compliment a plethora of treats. There will be an ice cream break, fruits break, beer break and special chef lunch.