Friday I flew out to Mountain View, CA to attend the Google Summer of Code Mentors Summit hosted at the Googleplex, Google's worldwide headquarters. Every year, two mentors from every organization are sponsored by google to attend the summit and I was offered the extra slot by Buddhike, the Fedora summer of code admin.
After the inevitable hubub w/ delayed flights and such (surprisingly my stow-away bag actually made it!), I arrived at the hotel on Friday night intime for the pre-summit dinner. On Saturday shuttles were available to transport us from the hotel to the Googleplex which I have to say in quite impressive. From architecture of the buildings, to the modern artwork scattered around the complex, to the meals/beverages/snacks, and even random bicyles available for any employee to just pickup and use, the complex lives up to the legend! (hover over images for descriptions, click for full sizes)
The summit was very much developer centric which I very much enjoyed, as most of the other conferences I attended included a mix of sys-admin and developer tracks. Obviously the driving event was a summer of _code_, so many of the attendees were software engineers themselves, mentoring students doing the development. Some projects were bigger than others, some well established, some not, but it was a great mix of contributors from across the industry working on many cool things.
Among the best of the presentations I attended included roundtable discussions on the latest languages and language features being used in the industry, different collaboration tools that the projects are using and their thoughts on them, and one on developing tools to quantify and measure community metrics and individual contributions. During the lightning talks (one minute a piece), I showed off Zuhao's isitfedoraruby project, and extensively promoted his work, as well as Sammy's and Nitesh's contributions to Aeolus throughout the entire conference.
I also held an impromptu session on the JSON-RPC protocol during the afternoon which was a last minute thing, but was able to leverage my presentation and demo of rjr in Brno from a few months back. This led to an good discussion with some interesting ideas emerging from it and even a couple adopters!
Saturday night was the Summit Dinner Party at the hotel, italian food, good mingling, and even a dip in the pool and hottub! This morning I checked out of the hotel and attended more sessions before wrapping up the trip (I am currently blogging this from SFO prior to catching my red-eye home).
I have to say this might just be the best conference I've been to so far. The talks and presenters were phenomenal. Even the attendees were constituted of some of the brightest of the industry, so many conversations lead to insightful perspectives and different conclusions than I hadn't come upon so far. I hope to be able to participate in the GSoC and maybe attend the summit again next year. Until next time, happy coding!
RJR uses eventmachine on the backend to process incoming messages over tcp/amqp/http/websockets/etc and dispatch json-rpc requests to registered handlers. It also employs a built in thread pool to hand off requests to the dispatcher so that the reactor isn't blocked. What results from combining the reactor pattern with a thread pool is a highly reliable concurrent event processing system.
The reactor central to eventmachine and the design pattern itself processes events one after another in a serial manner. Events are executed in the order that they arrive and no event executes until the one before it completes. Events can come from multiple sources and the reactor will take care of the serialization necessary to ensure data integrity.
A developer initializes the necessary connections and receives events by registering callbacks to be triggered on their invocation. Since the reactor blocks on any operation, the developer needs to ensure that his/her callbacks execute quickly and return control back to the reactor to continue processing events. Threads can be used to accomplish this, but spinning up a thread is an intensive operation, so a managed thread pool can be used as a nice solution that allows the developer to execute callbacks quickly and asyncronously without blocking the reactor.
Of course any resources leveraged by the callbacks will need to be protected from concurrent access but the nice thing is that if care is taken, the reactor itself can be used to handle this. In the callbacks launched by the thread pool, the developer can leverage the event machine reactor to schedule additional work that will be executed serially with the rest of the work already there. What results is an elegant / simple solution to schedule and process work concurrently with a built in mechanism to protect shared resources. Optimally the thread pool will incorporate a timeout mechanism that is able to kill jobs that exceed the timeout and restart their worker threads to keep things moving smoothly (as RJR does).
I would give this combined design pattern a name (perhaps Reactor Pool?) but I'm sure someone out there probably has already thought about this... and blogged about it... and uploaded an article to wikipedia... etc...