Scarlet 1.0 RC2 is out!

Short news just to let you know that the Scarlet second release candidate is officially out!

This is your last chance for submitting bugs, suggestions and feedback about Scarlet, prior to its final release, scheduled for the end of this month.

So don't hesitate to contribute to the unique Open Source clustering solution for your preferred enterprise issue tracking software!

Enjoy it!

Scarlet first release candidate is out!

Exciting news about Scarlet are coming!

The new Scarlet 1.0 Release Candidate 1 is officially out, with new features, several enhancements and fixes, and a brand new web site!
Can't wait for it?
Take a look at: http://scarlet.sf.net!

Talking about the technical side of this new release, the most important changes concern the upgrade to Atlassian Jira 3.12, improved APIs for plugin development and a performance boost of about 20%.

However, what most excites me is the new Scarlet infrastructure, based on Sourceforge:

• The web site, with growing documentation.


• Forums and mailing lists, for easily getting help, sharing feedback and discussions, and staying in touch.


• A public Jira space (thanks to Atlassian), for actively contributing to the Scarlet development by tracking bugs and feature requests.


• A widely accessible download system.

This is to lay the foundation for a true open source community behind Scarlet, which is currently our primary goal ... together with providing you the best Jira clustering solution around, obviously!

Now, it's your turn!

See you at Javapolis!

I'm going to leave Rome and catch my flight for Antwerp.
Actual destination : Javapolis!

I will hold a BOF, so don't miss it.

See you there!

Owner Based Locking explained

If you attended my presentation at the Rome JavaDay about my real world experience in clustering Atlassian Jira, or if you took a look at my slides, you may already know that one of the challenges was the rewriting of the Jira caching system.
The hardest part of this challenge was to define the cache locking strategy.
That was because of two requirements, due to the Jira code and the way it has been clustered:

• The need to associate more caches under the same lock.


• The need to execute arbitrary code blocks atomically: that is, again, under the same lock.

So here it comes my idea of the owner based locking.
It's very simple and I'll explain it in a moment: others may find it useful, or elaborate on that for solving their own locking problems, or just provide useful suggestions.

Let's start with the concept of cache group. The cache group is the entry point for your caching system, where you create caches, put things and get back them and alike.

First step : when you create a cache into the group, assign it to an owner.

The owner is a string, and nothing more. It just serves two purposes: it's the name which associates different caches, establishing some kind of caches sub-group, and their lock.

Here it comes the second step : use the owner as a lock for different caches sub-groups.

This is a lock striping technique.
Lock striping techniques prescribe you to distribute your data in several "stripes" and split your big, fat, lock in several locks, assigning each one to a different stripe : this is done for enhancing thread concurrency, given that different threads will be able to concurrently access different parts (stripes) of your data because guarded by different locks.
In our caching system, the stripes are the different caches sub-groups, and the locks are the owners.
A code snippet will help clarifying.
Here is how a value is retrieved from a cache into the cache group:

    public Object get(String cacheName, Object key) {
        CacheHolder holder = (CacheHolder) this.group.get(cacheName);
        String owner = (String) holder.getOwner();
        synchronized (owner) {
            Map cache = holder.getCache();
            return cache.get(key);
        }
    }

As you can see, the synchronized variable is the owner string: by doing so, caches with the same owner will be protected by the same lock, while caches with different owners will be accessed concurrently, but without compromising the whole thread safety.

Finally : use callbacks for atomically executing code blocks.

This is best explained by first showing the callback interface:

    public interface AtomicContext {
     
        public Object execute();
    }

And how it's used into the cache group:

    public Object executeAtomically(AtomicContext context, String owner) {
        synchronized (owner) {
            return context.execute();
        }
    }

As you can see, the execute() method is executed atomically under the given owner lock.
However, here I have to raise a warning flag: if the implementation of the execute() method uses caches belonging to other owners, it may cause deadlocks; so take care and use only caches whose owner is the same as the one provided to the executeAtomically() method!

That's the owner based locking.
You can take the full source code of the cache group used for clustering Atlassian Jira from the Scarlet Jira extension distribution.

Any feedback will be highly appreciated.

Cheers!

News about Scarlet

One month has passed since my last post, due to the fact that I've been very busy working at the hottest (well, maybe I'm a bit biased here...) Jira extension around : Scarlet.
Here are some news about it:

• Me and my colleague and friend Ugo talked about our experience in clustering Jira with Terracotta at the Rome JavaDay: people really appreciated it, and if you weren't there (or if you liked us so much that you want to read them again) you can take a look at the slides (in English language) here.


• We've just released the Scarlet Beta 2 version! Take a look at the full announcement here.

As always, every kind of contribution will be welcome.
See you!