A mentor's take on GSoC

There are only few days till Google Summer of Code's 'Pencils Down' moment. This was my first year as mentor (or as anything for that reason) and now that the whole thing is fresh in my mind, it is a good time for me to write down my conclusions.
From my previous experience with junior developers, I knew that they need time "to boot up", to become productive. And not any kind of time, but quality time: you need to be there to make sure they ask the questions when needed and also that they understand the answer. Now the "be there" part, the physical collocation, is missing in this context. With GSoC there's a high chance (like in my case) to have your student on a totally different time zone (5.5 hour as it happened). 
On top of that, the module we wanted implemented was, even though isolated from the rest of the system, rather complex. These said, I was rather sceptic on the output of this endeavour. 

And how did it end? The student outperformed. And the mentor enjoyed it, a lot actually: it's a good feeling to see someone learning at a fast pace. And the enthusiasm is contagious.
   
Below's my take on what we did good, what we could have done better and what we saw around.

The good  
The best thing we did by far was to take our time and interview each candidate properly, rather than only rely on their melange submission for evaluation. Not only that the ranking of the students changed after the interviews, but we got an clear winner. 
The other thing we did was to clearly define the tasks to be worked on for few weeks in advance. That helped keeping focus on relevant tasks and was an effective way to define (and adjust) our expectations.

Could have done better
The setup. While writing code makes juniors and seasoned developer alike enthusiastic, setting up a build system or automating the test suite runs can be a major put-off for the the former. Setting up the project and then showing the student why the scripts(in our case) are needed and how were they written can not only gain time, but also keep the energy level high without compromising on the things the student learns. 

The bad
I think this was the most debated problem on the mentor's mailing list. Close to the evaluation period (mid term or final), the were mentors in doubt on whether the student should pass or not. I haven't encountered that myself, but I can understand the "was it maybe me" feeling you can get in such a situation. 
My only solution to this problem (besides experience) is to think about it in advance, and act quickly. The moment you feel "you are wasting time" (vs. teaching) you should make that very clear to the student. And if things don't get better act/stop the collaboration. 

I think that pretty much covers it all. But before that, a BIG thanks to both Google and my student for this prime experience!

Cheers,
Mircea

Infinispan and OGM at PT.JUG

Sanne Grinovero and myself will talk about Infinispan and OGM at Portugal JUG in Coimbra on the April 18. This join talk covers an introduction to Infinispan and its main use cases followed by a presentation about NoSQL and Hibernate OGM. Thanks to Samuel Santos for inviting us and really looking forward to meet with the community!

Cheers,

Mircea

50 minutes worth spent @ Codemotion IT

If you're lucky enough to participate at this year's Rome's Codemotion then my Infinispan in 50 minutes presentation might be an option to consider: this is an overview of the Infinispanecosystem which focuses on what are the problems our data gridcan help you solve.
The presentation is on the 23 of March starting at 9:50 AM and contrary to its title, it lasts only for 40 minutes - but don't worry, I'll be around for entire duration of the conference so feel free to come and ping for a chat!

Cheers,
Mircea

Participating at Miralce Open World 2012

I'll be presenting at this year's Miralce Open World with a talk on how Radargun is used for measuring Infinispan's performance. I think the topic is interesting for anyone that needs to prototype applications built using in-memory datagrids such as infinispan.
So if you are around and you are interested in this topic, or just want to say hi, then look for the guy with the Infinispan t-shirt (and my name on the badge)!

Cheers,
Mircea

Enhanced reporting in Radargun

Thanks to Galder Zamarreño, Radargun is now able to report information about memory consumption, CPU and GC usage. The information is being recorded from the time the benchmark starts to the time it is completed, excluding the warmup phase. A time-based graph is then generated - but enough talking, a picture makes more than a thousands words:

The diagram below compares the memory consumption between two Infinispan versions running Radargun's Web Session Replication benchmark .
CPU information is also captured:

Note: in the above diagram the GC activity is very low and it gets blurred in the graph. In both graphs the benchmark ran for 175 seconds - not a very realistic run.

At the moment this feature is only available for local benchmarks, and can be enabled through the 'sysMonitorEnabled' attribute:


Cheers,
Mircea

Fewer deadlocks, higher throughput

Here's the problem: first transaction (T1) writes to key a and b in this order. Second transaction (T2) writes to key b and a - again order is relevant. Now with some "right timing" T1 manages to acquire lock on a and T2 acquires lock on b. And then they wait one for the other to release locks so that they can progress. This is what is called a deadlock and is really bad for your system throughput - but I won't insist on this aspect, as I've mentioned it a lot in my previous posts.

What I want to talk about though is a way to solve this problem. Quit a simple way - just force an order on your transaction writes and you're guaranteed not to deadlock: if both T1 and T2 write to a then b (lexicographical order) there won't be any deadlock. Ever.

But there's a catch. It's not always possible to define this order, simply because you can't or because you don't know all your keys at the very beginning of the transaction.

Now here's the good news: Infinispan orders the keys touched in a transaction for you. And it even defines an order so that you won't have to do that. Actually you don't have to anything, not even enable this feature, as it is already enabled for you by default.

Does it sound too good to be true? That's because it's only partially true. That is lock reordering only works if you're using optimistic locking. For pessimistic locking you still have to do it the old way - order your locks (that's of course if you can).

Wanna know more about it? Read this.

Stay tunned!

Mircea

Single lock owner: an important step forward for Infinispan's transactions

The single lock owner is a highly requested Infinispan improvement. The basic idea behind it is that, when writing to a key, locks are no longer acquired on all the nodes that own that key, but only on a single designated node (named "main owner").

How does it help me?

Short version: if you use transactions that concurrently write to the same keys, this improvement significantly increases your system' throughput.

Long version: If you're using Infinispan with transactions that modify the same key(s) concurrently then you can easily end up in a deadlock. A deadlock can also occur if two transaction modify the same key at the same time - which is both inefficient and counter-intuitive. Such a deadlock means that at one transaction(or both) eventually rollback but also the lock on the key is held for the duration of a lockAquistionTimout config option (defaults to 10 seconds). These deadlocks reduces the throughput significantly as transactions threads are held inactive during deadlock time. On top of that, other transactions that want to operate on that key are also delayed, potentially resulting in a cascade effect.

What's the added performance penalty?

The only encountered performance penalty is during cluster topology changes. At that point the cluster needs to perform some additional computation (no RPC involved) to fail-over the acquired locks from previous to new owners.
Another noticeable aspect is that locks are now being released asynchronously, after the transaction commits. This doesn't add any burden to the transaction duration, but it means that locks are being held slightly longer. That's not something to be concerned about if you're not using transactions that compete for same locks though.
We plan to benchmark this feature using Radargun benchmark tool - we'll report back!

Want to know more?

You can read the single lock owner design wiki or/and follow the JIRA JIRA discussions.