Java to the Limittag:typepad.com,2003:weblog-5072222014-06-02T22:44:35+02:00Knowing your wisdom's insufficience is yet a kind of omniscienceTypePadSwift Languagetag:typepad.com,2003:post-6a00d83455f7ed69e201a3fd15d605970b2014-06-02T22:44:35+02:002014-06-02T22:44:35+02:00# On the Swift Language Today, Apple announced a new programming language, Swift. Swift is an OO language, with a scripting like syntax, static types, local type inference, value types, tuples and pattern matching. It's stateful, and pretty straight forward...Kresten Krab Thorup

On the Swift Language

Today, Apple announced a new programming language, Swift.

Swift is an OO language, with a scripting like syntax, static types, local type inference, value types, tuples and pattern matching. It's stateful, and pretty straight forward mix of features from JavaScript, Groovy, Scala, Java, and C#.

In good tradition with Apple (and NeXT), the language is extremely pragmatic and focusing on seamless integration with the existing platform. So it should be possible to mix Objective-C and Swift in the same application. This could turn out to be a major win for the language, just like Objective-C was great in that it let you mix Objective-C (the new language) with C (which had all the libraries).

Memory Management

It's ARC (Automatic Reference Counting) again. Granted, ARC is much nicer than the old new/free regime of Objective-C, but so far from what we're used to expect in a modern language.

Especially with complex structures that easily come from some GUI elements referring to model objects, which can easily lead to cycles in the object graph.

Value Types

Swift has value types of sorts. Whenever you assign a reference to an immutable variable using let x = <expr> as opposed to var x = <expr>, swift makes a semantic copy of the value being assigned, making the value immutable in the process. This copying recurses until the types (of generics and/or members) are of reference (a.k.a. mutable) type.

This provides a relatively smooth path to introduce more immutability in a codebase; because mutable and immutable things of the same type can coexist. What is yet to be proven is how this translates into reality ... perhaps someone from the OCaml world (which also has a mix of mutable and immutable) can shed light on that.

Concurrency

Surprisingly, the reference manual mentions nothing about threads or processes or the like. So from the outset there's not concurrency story.

IMHO, one of the hardest parts of writing apps is the concurrency which has many sources, but most notably concurrent GUI updates and network activity.

So initially, this looks a bit dissapointing, but maybe there is a way out. Swift's value types and pattern matching might be a good combo to provide passing things from one thread to another. But as long as there is a strong undercurrent to provide backwards compatability and integration with Objective-C as it is, this will be very hard to accomplish as far as I can see.

There is only one way to do concurrency right: isolation. Just like Rust or Erlang has it, each process needs a separate memory space, and shared data needs to be 100% controlled by the system. It's the only thing that I have seen which works.

http://www.javalimit.com/2014/06/swift-language.htmlHow Could it go so Bad?tag:typepad.com,2003:post-6a00d83455f7ed69e2019102609158970c2013-05-21T16:22:09+02:002013-05-21T16:22:09+02:00This past weekend I’ve been reading Roubini and Mihm’s [Crisis Economics](http://www.amazon.com/gp/product/B00B9ZHWK6/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=B00B9ZHWK6&linkCode=as2&tag=krekrasblo-20), a worthwhile read if you’d like to understand *what went wrong*. ![Crisis Economics](http://cache0.bdcdn.net/assets/images/book/medium/9780/1410/9780141045931.jpg) I’m “just an ordinary guy” when it comes to international-scale economics; and like most people probably...Kresten Krab Thorup

This past weekend I’ve been reading Roubini and Mihm’s Crisis Economics, a worthwhile read if you’d like to understand what went wrong.

I’m “just an ordinary guy” when it comes to international-scale economics; and like most people probably — I’ve been baffled by what the financial crisis that peaked in the fall of 2008 was really about. This book is a great and neutral exposition of what really happened and what we should do about it.

What Happened?

The first two thirds of the book is a history lesson on what happened, a parallel tale of 1929 and 2008. The last part talks about what we should do about it, and how the concequences of the US’s enoumous current trade deficit may unfold.

The latter part is the more interesting of course. The authors make it very clear that the crisis is not directly the fault of the individual actors in the financial system; it’s the system itself that is fundamentally broken.

One central principle that was broken in the recent crisis was that central banks bailed out (a) financial institutions that were not just illiquid but they were also insolvent, and (b) they also bailed out non-banks. Both represent moral hazards, as it may cause people to expect such bail outs in the future; even in non-bank financial institutions, which is likely to make them take risks they would not otherwise undertake.

What should be done?

The crisis is an eminent opportunity to change legislation. Generally, the legislation need to guide system actor’s motivations and increase transparency.

Compensation in the financial sector should be restructured so as to value long-time gains rather than quick wins. The authors make it an explicit point to say that it is not necessarily the size of compensation which is the problem; it’s the structure. There needs to be more skin in the game.

The fact that rating are payed for by the very institutions that are selling financial products, is fundamentally broken. IMO, ratings should be provided to the public free of charge by truly independent bodies — national or supernational, and the more the merrier. Until then, never trust an AAA rating again.

Derivatives need to be controlled. It’s absurd that the system alows anyone to buy CDS’s “bankrupcy insurance” for a any 3rd party; even without having an equity interest in that party. It’s like buying fire insurance for your neighbours house ... which might motivate me to play around with some matches ...

Too-big-to-fail oriented legislation is bullshit; rules should apply to everyone. If anything, corporations that are too large to fail should be split up.

The book contains many more suggestions for what could be done, the above are some of the more important ones it seems.

What’s Next?

According to the authors it is inevitable that soon, the US’s status as the world’s primary economy will fade, and likely be replaced with a century with Chinese dominance. The US Dollar cannot continue to be the reference currency. Hopefully this shift will happen in an orderly fashion, but if the US tries to devaluate the dollar by inducing too much inflation (reducing the value of treasury bonds) we might see a “run on the bank” out of the ordinary.

Conclusions

Great book. There’s a lot of “doom day” books out there, this is not one of them. It provides a solemn and trustworthy account of what happend and argues what we need to do.

http://www.javalimit.com/2013/05/how-could-it-go-so-bad.htmlConsistency Eventualistag:typepad.com,2003:post-6a00d83455f7ed69e2017ee45ce15c970d2012-10-22T23:47:29+02:002012-10-23T11:13:35+02:00Here is just a short note on the unfortunate choice of name for the concept Eventual Consistency. To many non-native speaking people, it sounds like Maybe Consistent. Many languages have a word derived from the latin word eventualis (German: eventuell,...Kresten Krab Thorup

Here is just a short note on the unfortunate choice of name for the concept Eventual Consistency. To many non-native speaking people, it sounds like Maybe Consistent.

Many languages have a word derived from the latin word eventualis (German: eventuell, French: éventuel, Danish: eventuelt, …) which in these languages literally means possibly or perhaps - a word used to denote something which may happen, or maybe not. For instance, we would use it in phrases such as [replace underlined word with with "our" version of eventual]:

Could you perhaps do me a favour?

What do you think of the possibly fatal outcome?

To an average Dane, for instance, eventually fatal doesn't necessarily sound bad; likewise eventually wonderful is not necessarily good.

This is of course very unfortunate us who want to promote eventual consistency as a tool to provide better scalability and availability in large-scale distributed systems. The term makes it sound flaky, or "perhapsy". "If you are lucky - and the planets all line up correctly - yes, then it will eventually be consistent." It just rings wrong.

So, from now on I propose that we all call it delayed consistency, which at least to my ear sounds much more right. It sounds like we will eventually get there :-)

http://www.javalimit.com/2012/10/consistency-eventualis.htmlErlang is not a Concurrent Functional Programming Languagetag:typepad.com,2003:post-6a00d83455f7ed69e20154327e376e970c2011-05-24T01:14:24+02:002011-05-26T10:58:20+02:00Whenever developers fall in love with Erlang (as many tend to do these days) they are too often busy promoting it to their friends and colleagues as a cool language for *concurrency* and *functional programming*. Which is a pity, for...Kresten Krab Thorup

Whenever developers fall in love with Erlang (as many tend to do these days) they are too often busy promoting it to their friends and colleagues as a cool language for concurrency and functional programming. Which is a pity, for several reasons.

It intimidates people.

It's wrong.

The intimidation factor

Functional programming is scary. Most developers for whom Erlang may be a relevant alternative are probably doing server-side programming in Java or C# today: they most likely know by experience that concurrent programming is damn hard, and functional programming was something they tried +10 years ago in a computer science class in their undergraduate work. So if you focus on those two aspects you are almost certain to intimidate people, and convince them that this is really difficult stuff to lean.

As we all know ... "people don't want to buy quarter inch drills, they want quarter inch holes." Likewise with programming languages: If you want to advocate Erlang to your friends and colleagues, focus on the benefits. It's not really a key selling point of Erlang that it has certain resemblances with some functional programming languages, neither is it a primary quality that it is really easy to spin up a million processes. Those are good-for-nothing arguments, that just sound flashy, and focus on some secondary aspects of the artifact called Erlang.

Focusing on concurrency also has the problem that most people don't even know what it means, nor why it is important. On blogs and online media there is a lot of discussion about on issues with utilizing multi-core CPUs, the free lunch is over, etc. etc. Combine that with your average engineer's performance fetich, and many people will intuitively think that the concurrency is there to get performance. Why else would you bring such mind-boggling pains upon yourself?

Being wrong

When I started looking into Erlang two years ago, I was wrong. I was looking for something to make concurrent asynchronous programming more intuitive, because those things were (and still are) obviously hard in the Java world I'd been living in for the last 15 years. It is difficult to write programs that utilize multicore; but in many cases -- I've realized -- that is of lessor importance. I went looking for one thing, but found something much more important.

Erlang is about building reliable systems.

That's it: Erlang is about making software systems that are fault tolerant, given that just about everything about the system has problems: hardware and networks fail (often because of human err), the software we write has bugs that need fixing, requirements change all the time, and we want the system to run 24x7.

You can almost hear the designers saying: "Let's make a tool to build reliable systems; what do we need to make that happen?" Then then they went off and solved all the hard problems involved with that, and to this date, Erlang is the only "full package" that can do that. And as complete packages go, there are some rough edges and individual things that could be made better, but ... as a whole it's pretty damn good. And don't get me wrong: Software is not automatically reliable because it is written in Erlang ... rather, Erlang is a toolbox that allows you to write reliable software systems.

What is Erlang then?

First of all, Erlang introduces mechanisms to contain and manage faults. When a problem happens in an Erlang system, it doesn't take down everything with it. This is hard to grasp for a Java programmer where you're used to a bad null pointer error or something that will take down the entire application. Erlang is more like an operating system which itself runs inside an OS-level process: if one component faults, then its resources are properly reclaimed and only that component is shut down.

To manage faults, Erlang has mechanisms much like Unix signal handlers, that will notify other components about faults. These are called links and monitors. Monitors are one way (used to observe), whereas links are bidirectional, and can be used to establish strong aggregation-structures of Erlang components so that they "die in unison": if one goes down the integrity of the others is also at risk.

In order to make a system reliable, you also need to support running "the system" on multiple computers. To this end, Erlang has transparent distribution so you can have a component one one physical machine monitoring (or being linked to) a component on another machine. If an entire (virtual) machine dies, components on the other machine will observe that as if all the individual components on the failing machine faulted.

The process abstraction is used to capture all of the above. I said "component" but that really is process, which is something we all know well already. In Erlang, processes don't have threads, and processes can't see or touch each other's data. Just like in an operating system process. Erlang processes are individually sequential; and so an Erlang system is really just a set of Cooperating Sequential Processes. It reduces the inherent concurrency to just a bunch of sequential programs. If you want, you can think of processes as actors; which is really just how objects should have been in the first place. Actors encapsulate their state, and they use message passing to interact.

Further, you need to have a model for fixing bugs while the system is running. That's the key feature of Erlang, The Movie. At its core, Erlang has features to support upgrading code in flight, which is also one of the reasons why Erlang is not a statically typed language: if you need to change your data structures in flight, you also need to change the types. While code upgrade is something which is very handy for development, it is not at all easy to do properly in production. I've heard that for some of Ericsson's telephony systems where they do live upgrades, they spent as much time developing and testing the upgrade as they do developing and testing new features. The frameworks and libraries that come with Erlang help you in many cases, as long as you stay within certain limits.

But perhaps most importantly, Erlang is just plain simple. Erlang code is compact, and (once you get used to it) very easy to read. Compared to coding Java, it almost feels like cheating.

So to get all these goodies, you have to learn some new syntax. Get over it.

Before you jump to conclusions and barf at me in the comments below, keep in mind that I do know Erlang very well. I've written an alternative Erlang VM, and I was awarded "Erlang User of the Year 2010". So, I do know that Erlang is a concurrent and somewhat functional programming language. But that's not the point.

http://www.javalimit.com/2011/05/erlang-is-not-a-concurrent-functional-programming-language.htmlUsing Links to Index Riak objectstag:typepad.com,2003:post-6a00d83455f7ed69e201538e21d5f6970b2011-04-26T13:54:01+02:002011-04-26T14:25:42+02:00Riak doesn't come with means to do secondary indexes out of the box. This limits many applications of Riak; and it's a bit tricky to implement correctly oneself. The module [`riak_link_index`](http://github.com/krestenkrab/riak_link_index) provides a mechanism that can be applicable for some...Kresten Krab Thorup

Riak doesn't come with means to do secondary indexes out of the box. This limits many applications of Riak; and it's a bit tricky to implement correctly oneself.

The module riak_link_index provides a mechanism that can be applicable for some situations, providing means to create synthetic (secondary link index) objects triggered by a Riak commit hook. The mechanism work by defining a function that names these synthetic objects as a function of the primary object body.

Basic Example

Assume the primary object contents being stored under the name dogs/ABC01 is

Then a secondary index object will be created named /riak/people/Peter, which contains a Riak link pointing back to dogs/ABC01.

That's it, basically. There are a few extra details though.

Composability by Tagging

Indexes are virtual entities not tied to a particular bucket; but the indexing function needs to be "installed" in the bucket being written to. However, multiple buckets may have objects that get indexed the same way, and the "index buckets" (in the above case the /riak/owns bucket) may contain different kinds of indexes. This kind of composability is controlled by assigning a unique tag to each indexer.

When you install an indexer, you also name it's tag. It could be that in the above example you choose the tag "owns_dog", then you can use a link-walk query like this:

curl http://127.0.0.1:8091/riak/people/Peter/_,_,owns_dog

To return all the dogs that are owned by peter. But the people/Peter object can also contain links to objects that are indexed by another indexer with it's own tag; say the houses that people own.

Under the hood

What really happens in the above example is that the indexer function runs in the precommit phase and creates links attached to the primary object, pointing to the index objects, tagged with idx@owns_dog. So, the object dogs/ABC01 will get a link

Link: </riak/people/Peter>; riaktag="idx@owns_dog"

The post-commit phase of storing the dog object, will then go to the targets of all the idx@-prefixed links (the index objects), and make sure that those each have a link pointing back to the dog.

So, in stead of using the indexer function, you can also just provide those links when you push the object in the first place; and then the indexer function doesn't have to be installed.

The index objects contain a data structure used to ensure the consistency of the resulting links; that is if two different PUTs to some primary objects mutate the same index object, then the index object may end up having a write conflict (siblings), and the data structure makes sure that such conflicts are resolved properly with it's own set of vector clocks.

Because of that, you cannot use the index objects to contain other stuff. The data structure contained therein is only for the use of the riak_link_index stuff.

http://www.javalimit.com/2011/04/using-to-index-riak-objects.htmlIntroducing Vector Mapstag:typepad.com,2003:post-6a00d83455f7ed69e20147e2b51462970b2011-02-21T02:43:53+01:002011-03-03T13:28:50+01:00> This post introduces a new data structure - the vector map - which solves some issues related to storing collections in MVCC data stores. Further, vector maps have some super nice use cases for "occasionally connected" systems. > The...Kresten Krab Thorup
<div xmlns="http://www.w3.org/1999/xhtml"><blockquote>
<p>This post introduces a new data structure - the vector map - which solves some issues related to storing collections in MVCC data stores. Further, vector maps have some super nice use cases for "occasionally connected" systems. </p>
<p>The idea warrants a more rigorous discourse, but I need to get it off my chest, so here is a blog entry describing it.</p>
</blockquote>
<div style="float: right; margin-left: 1em"><script type="text/javascript">
var topsy_nick = "drkrab";
var topsy_style = "big";
</script>
<script type="text/javascript" src="http://cdn.topsy.com/button.js"></script></div>
<p>Modern distributed data stores such as CouchDB and Riak, use variants of <em>Multi-Version Concurrency Control</em> to detect conflicting database updates and present these as multi-valued responses.</p>
<p>So, if I and my buddy Ola both update the same data record concurrently, the result may be that the data record now has multiple values - both mine and Ola's - and it will be up to the eventual consumer of the data record to resolve the problem. The exact schemes used to manage the MVCC differs from system to system, but the effect is the same; the client is left with the turd to sort out.</p>
<p>This led me to an idea, of trying to create a data structure which is by it's very definition itself able to be merged, and then store such data in these kinds of databases. So, if you are handed two versions, there is a reconciliation function that will take those two records and "merge" them into one sound record, by some definition of "sound".</p>
<p>From what I have seen, the "thing" stored is often itself a collection like a list or a hash map, and say that Ola and I both add new elements to the collection and store the results, the resulting multiple records are - with proper definitions - naturally mergeable; namely the list or map that contains the original entries plus both mine and Ola's.</p>
<p>So, this is the presentation of my idea: A <em>vector map</em>, which is a data structure that is designed to be used in this context. It also has other interesting applications as we shall discuss towards the end of this post.</p>
<h2>Vector Maps</h2>
<p>A vector map is defined as a set of <em>assignment events</em>, Key=Value, each such event being time stamped with a <a href="http://en.wikipedia.org/wiki/Vector_clock">vector clock</a> (hence the name). From a high-level point of view, a <em>vector map</em> can be seen as a hash table i.e., a collection key/value pairs.</p>
<p>Two vector maps can be reconciled (<em>VectorMap<sub>1</sub></em> ⊕ <em>VectorMap<sub>2</sub></em>), so that for each key, the "most recent assignment event" wins. If assignment events are in conflict (vector-clock wise concurrent), then the resulting value is multivalued.</p>
<p>The reconciliation function for vector maps is defined so that it is commutative i.e., it can be applied in any order i.e., </p>
<blockquote>
<p>A <em>⊕</em> B = B <em>⊕</em> A, </p>
</blockquote>
<p>It is also associative, </p>
<blockquote>
<p>A <em>⊕</em> (B <em>⊕</em> C) = (A <em>⊕</em> B) <em>⊕</em> C, </p>
</blockquote>
<p>which means that reordering done inside the database store, is insignificant to the resulting usage. </p>
<blockquote>
<p>In fact, <a href="http://wiki.basho.com">Riak</a> itself (the distributed key/value store) is just a big distributed and redundant version of this; which just goes to prove the versatility of the idea. So in a sense, a vector map is just a recursion over the Riak (Dynamo) concepts applied to a data structure.</p>
</blockquote>
<p>In the following we will define things a little more rigorously and provide some examples; and towards the end there is a discussion of how vector maps can be used.</p>
<h3>Assignments as Vector Clocked Events</h3>
<p>For the purposes of this discourse, we will model an assignment event as</p>
<ul>
<li>a <em>Key</em>, </li>
<li>a <em>Set</em> of values, and</li>
<li>a <a href="http://en.wikipedia.org/wiki/Vector_clock">vector clock</a>, <em>VC</em>, describing when the assignment happened,</li>
</ul>
<p>so an assignment event has the following form:</p>
<blockquote>
<p>Assignment :: VC: Key = [Value, Value, ...]</p>
</blockquote>
<p>We will let the set contain multiple values in case a conflict has been observed, but to start off with our sets will be single-valued.</p>
<p>Our system will use the vector clock to determine "who wins". Let's see what happens ...</p>
<p>To begin with, I do an assignment "X" = 4, and record this event:</p>
<blockquote>
<p>Assignment<sub>1</sub> = (krab:1) : "X" = [4]</p>
</blockquote>
<p>Reading: <em>at krab's time 1, "X" is bound to 4</em>. </p>
<p>Later, after observing my assignment, a colleague Ola, at his time 2, defines "X" to be 5</p>
<blockquote>
<p>Assignment<sub>2</sub> = (ola:2,krab:1) : "X" = [5]</p>
</blockquote>
<p>Now, the immediate beauty is that because each assignment is time stamped with a vector clock, we can easily determine that Assignment<sub>2</sub> happened after Assignment<sub>1</sub> (the vector clock says that Ole did indeed observe Assignment<sub>1</sub> before creating his own), and so if we see both we can discard the earlier one without loss.</p>
<h3>Conflict happens</h3>
<p>Now, what happens if Jens comes in, and based on only observing my original assignment, he reassigns "X" to be 7. We'll describe this with the following event:</p>
<blockquote>
<p>Assignment<sub>3</sub> = (jens:3,krab:1) : "X" = [7]</p>
</blockquote>
<p>To Jens, this is not problematic, but if someone observes both Assignment<sub>2</sub> and Assignment<sub>3</sub> they'll know that Jens did not observe Ola's time 2.</p>
<p>To make some kind of sense out of this, we define the reconciliation operator ⊕, describing the aggregation of knowledge we have when combining the known events.</p>
<blockquote>
<p>Assignment<sub>2</sub> <em>⊕</em> Assignment<sub>3</sub> = (krab:1,ola:2,jens:3) : "X" = [5,7]</p>
</blockquote>
<p>I.e., we describe that "X" has conflicting values 5 <em>and</em> 7 at a point in time which is after both Assignment<sub>2</sub> and Assignment<sub>3</sub>. </p>
<h3>Deleting values</h3>
<p>A further complication is what happens when we want to delete a binding, but this is handled quite simply by making a new assignment to a unique <code>tombstone</code> value which is somehow outside scope of other possible values; and then reconciling that into the current event set. This does have some interesting properties, because there is an observable difference between a binding that was never there, and a binding that was removed.</p>
<h3>Defining Reconciliation</h3>
<p>In the example above, we can see from the vector clocks that Jens had not observed Ola's assignment, and so we reconciled the two conflicting events by </p>
<ol>
<li>creating an artificial vector clock <strong>(krab:1,ola:2,jens:3)</strong> which is logically after both <strong>(ola:2,krab:1)</strong> and <strong>(jens:3,krab:1)</strong>, and</li>
<li>combining the bound values [5] and [7] into a set of values [5,7].</li>
</ol>
<p>Had it been obvious that one assignment happened before the other, we would simply had thrown one of them away, but because the two vector clocks were in conflict we have to recognize the conflict. </p>
<p>So the actual definition of reconciliation for two assignment events with the same key is as follows:</p>
<blockquote>
<p>VC<sub>1</sub>:Key=Set<sub>1</sub> <em>⊕</em> VC<sub>2</sub>:Key=Set<sub>2</sub> ≡ <br/>&nbsp; &nbsp; &nbsp; &nbsp;
VC<sub>1</sub> ≤ VC<sub>2</sub> → VC2 : Key = Set<sub>2</sub>;<br/>&nbsp; &nbsp; &nbsp; &nbsp;
VC<sub>2</sub> ≤ VC<sub>1</sub> → VC<sub>1</sub> : Key = Set<sub>1</sub>;<br/>&nbsp; &nbsp; &nbsp; &nbsp;
<code>otherwise</code> → lub(VC<sub>1</sub>,VC<sub>2</sub>) : Key = (Set<sub>1</sub> ∪ Set<sub>2</sub>)</p>
</blockquote>
<p>The reconciliation operator (o-plus) is commutative (just like good old addition), so we can use it to reconcile assignment events in any order and we'll always arrive at the same result in the end. Which makes it perfect for making decisions in a distributed system; because it means that even if we get to know about events in different order, the state will eventually reconcile to the same value (eventually meaning when we've seen all the events).</p>
<p>The definition uses the <code>lub</code> (least upper bound) on two vector clocks, which combines two such by taking the maximum local time stamp for each agent present in two sets of vector clocks:</p>
<blockquote>
<p><strong>lub(</strong> VC<sub>1</sub>, VC<sub>2</sub> <strong>)</strong> ≡ <br/>&nbsp; &nbsp; &nbsp; &nbsp;
∀ a ∈ <em>agents</em>(VC<sub>1</sub>) ∪ <em>agents</em>(VC<sub>2</sub>) <br/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
a : max( <em>time</em>(VC<sub>1</sub>,a), <em>time</em>(VC<sub>2</sub>,a) )</p>
</blockquote>
<p>Where <em>time</em>(VC,a) is 0 (zero) if VC does not list an agent a. For example</p>
<blockquote>
<p><strong>lub(</strong> (b:3), (a:1, b:2) <strong>)</strong> = (a:1, b:3)</p>
</blockquote>
<h2>What is this good for?</h2>
<p>You may rightly say that this doesn't solve the problem, it just pushes the problem one level down. And that's right; but ... it does solve an interesting range of problems, and with some care you can often structure your usage of keys in vector maps so that you can avoid conflicts all together.</p>
<p>Further, since your favorite data store already does this for you ... you may say that you can just split your map into individual key/value bindings and store those in the database. But that comes at a price of network round trips and data locality. </p>
<h3>Use case: Modeling Relationships in MVCC data stores</h3>
<p>Vector maps are really nice for modeling relationships inside MVCC databases. </p>
<p>Assuming you want to store a one-to-many relationship in Riak (say, order - order-item), you run into the problem on the one-side that it is likely to be concurrently updated if multiple items are added to the same order. </p>
<p>With vector maps, you can easily model the entire relationship as one order object which is just a vector map, where each item is stored with a distinct key. If that key is e.g. a sufficiently large random number, making it very unlikely that order-item-id's conflict, then you're pretty much home free. Alternatively, you can devise a mechanism so that each client of the system is able to construct globally unique keys (agent + sequence number).</p>
<p>For this use case, you'll see <strong>much</strong> improved performance also, because of the improved locality of reference. If your data store needs to go and fetch each individual order-item on the disk somewhere, then performance will be seriously hampered.</p>
<h3>Use case: off-line data</h3>
<p>Vector maps are great for off-line data, because they give a well defined meaning to the concept of synchronization (something I would really like my iCal to do :-) Synchronization is simply defined as the exchange of vector maps, storing the result of the reconciliation on both sides.</p>
<p>Such synchronization can happen in near-real time (peer-to-peer update) or as a delayed synchronization whenever there is contact to a server/peer.</p>
<p>This is perhaps the most interesting use case, because it an be used as a simple foundation for making data available to e.g. mobile clients in an "occasionally connected" system, in a way that makes sense for both online <em>and</em> offline mode.</p>
<h2>Implementation Issues</h2>
<p>Since it is a little complicated to manipulate a vector map, we need implementations in the most common languages out there to get it off the ground. I'm currently hacking on an Erlang and a Java version.</p>
<p>Working on this, and I have come to the conclusion that it would be great if vector maps have a well defined binary representation so that they can be meaningfully manipulated in a number of different contexts, easily stored and transmitted, etc. So, a special mime-type that lets multiple parties consume vector maps independent of programming languages.</p>
<p>If vector maps had it's own mime type and well defined data representation, data stores such as Riak or CouchDB could even do the reconciliation automatically before serving the data to a client.</p>
<p>So, right now I am working with a protocol buffers definition that looks like this on the wire, to be encoded as Content-Type <code>application/x-protobuf;proto=vectormap</code>, and likely a also a JSON representation <code>application/json;schema=vectormap</code>.</p>
<pre>
message VectorMap {
repeated Entry entries = 1;
}
message Entry {
required string key = 1;
repeated Clock vclocks = 2;
repeated Value value = 3;
}
message Value {
optional string mime_type = 1 [ default = "application/json;charset=utf-8" ];
optional bytes content = 2;
optional bool deleted = 3 [ default = false ];
}
message Clock {
required string node = 1;
required uint32 counter = 2;
required uint64 utc_millis = 3;
}
</pre>
<h2>Conclusions</h2>
<p>The Dynamo idea of using vector clocks to time stamp data is great, but I think the power of the idea goes quite a bit further if the logic is brought all the way to the client.</p>
<p>CouchDB tries to do this by suggesting that client devices (mobile devices) should have a full fledged CouchDB running there. But I think that exposing data this way makes the mobile client model much more manageable. This entire idea can be wrapped up in a single Java class which is easily deployed in a Android app; and it is sufficiently simple to be implementable in a range of programming languages.</p>
<p>What do you think?</p>
</div>
<img src="//feeds.feedburner.com/~r/javalimit/~4/y14yPfqSqJ4" height="1" width="1" alt=""/>http://www.javalimit.com/2011/02/the-beauty-of-vector-clocked-data.htmlAbout Version Vectors (a.k.a. Vector Clocks)tag:typepad.com,2003:post-6a00d83455f7ed69e20147e1ff5fd3970b2011-01-26T19:53:11+01:002011-01-27T19:09:26+01:00The last few weeks I've been working on understanding vector clocks (or rather, [version vectors](http://en.wikipedia.org/wiki/Version_vector)). When working with distributed data stores like [Riak](http://wiki.basho.com) and [Voldemort](http://project-voldemort.com/) which are using this to manage consistency, it is important to have a deep understanding...Kresten Krab Thorup

The last few weeks I've been working on understanding vector clocks (or rather, version vectors). When working with distributed data stores like Riak and Voldemort which are using this to manage consistency, it is important to have a deep understanding of what kind of consistency they provide, and how to design systems that work well with these structures.

Versions of shared spreadsheets

Adam and Eve are working on a shared Excel spreadsheet, and they have devised a clever scheme for versioning it, so they can detect conflicting edits.

Their idea is that the document has two version numbers embedded in the file name. When Adam saves a new version, he increments his number; and likewise for Eve. After some exchanges and edits, the document is now called doc_adam3_eve4.xls (Adam in version 3, Eve in version 4). The rules of the game are thus:

If Adam updates the document, he shall increment from adam3 to adam4, and so name the next version doc_adam4_eve4.xls, whereas

if Eve updates the same document she shall increment eve4 to eve5 and call the result doc_adam3_eve5.xls.

Because both Adam and Eve have their own version scheme, they can make edits and when they share their updated documents they can easily detect if they have made concurrent edits. Eve will bring her maximum eve-numbered version, and Adam will bring his maximum adam-numbered version. Then a mechanism depicted in this diagram can be used to detect a conflict:

Given version {adam=3,eve=4} (represented by the white square in the middle), you can see which versions are logially "after" and "before" that version.
Versions colored yellow are in conflict with doc_adam3_eve4.xls, representing logically "concurrent" edits.

The great thing is that this scheme extends to any number of participants. It's just easier to depict in a two-dimensional way, but the same mechanism works for any number of vector dimensions. Missing participants are assumed to have version 0.

Vector Time. The numbering scheme above is an example of a vector clock which can be used to describe temporal relations between events in a distributed system. Generally speaking, a vector clock is a list of (place, version) pairs, in which each place occurs at most once.

Really, we should perhaps talk about version vectors because the time-notion does not exactly refer to our intuitive notion of time, but to some monotonous increasing series of "versions" issued at each "place".

version vectors and version vectors have a partial ordering, which captures the idea of before/after a given point in vector time. It's partial because there exists pairs of version vectors so that one is neither before nor after the other; they are "concurrent".

If you have a set of version vectors, there is thus a subset hereof which are "maximal" (most recent). This set contains only one element if there is no conflict.

If you use version vectors to give versions to documents, then it is obviously great if there is only one such "most recent" document. If there is more than one "most recent" then at least you have narrowed it down to the versions to take a closer look at.

Assembling the Jigsaw

Regardless of their cleverness, Adam and Eve are often in trouble, because often they have more than one "most recent" Excel spreadsheet when they get together (say, doc_adam4_eve4.xls and doc_adam3_eve5.xls mentioned before), and so they have to sit there and take their spreadsheet apart, resolve the conflicts, and put it back together. Once they have resolved their conflicts they can name the new version doc_adam4_eve5.xls which is "after" both of the aforementioned ones and be back on track.

Now Justin (he's a really smart programmer) comes along to help them write a new spreadsheet application called Schemix that solves their issues. Schemix represents spreadsheets such that each cell value in the spreadsheet has it's own version number using version vectors.

Here's a document in Schemix

And here is how Schemix represents this data after Adam and Eve have been working on it for a while.

The right-most column is the version vector timestamp for the corresponding cell. So, in stead of giving the entire document a single version, each cell in the spreadsheet has its own independent version number. Whenever Adam saves his document, the cells he has modifies will have their version number bumped up one.

This versioning scheme allows any two such Schemix documents to be merged, by comparing the cells individually using the scheme Adam and Eve were using above. Assume the aforementioned document was merged with this:

Merging two Schemix documents is like assembling a jigsaw puzzle from two sets of jigsaws puzzle pieces:

For some pieces, there will be two identically versioned ones (such as cells B1 and B2) and so you just choose any one and throw the other away.

For some pieces, one is "newer" than the other (for cell A2); and so you just keep the most recent one and discard the other.

but, but, but for some there may be a conflict, and so the cell becomes multi-valued. Say, both Adam and Eve concurrently change the cell A1, but to distinct values. Then you're in trouble; but luckily much less so than before because the conflict only pertains to that single cell.

When cells are in conflict as a result of merging two Schemix documents, they are allowed to have multiple values. In Schemix, this is obviously just represented as a multi-values GUI element (a drop-down), so that once you have a merged document, you can easily edit it to resolve the conflict.

Inremental Updates

Version vectors are really nice, because you don't need entire documents to be able to do consistent merges. If Adam and Eve can see each other via a peer-to-peer channel, they can just as well send updates to each other by sending the cell values incrementally. The fact that each cell carries it's own consistency structure makes this scheme applicable to bulk- or incremental merges alike.

Relation to NoSQL

As mentioned above, this idea of version vectors is important because it is a fundamental notion underlying many of the new distributed NoSQL data stores, such as Voldemort, and Riak. The cell-names A1, B2, and so on are similar to the keys used in these systems, and the notion of version vectors described here is close to what they do. A Riak store is really just one giant version of the Schemix spreadsheet I described above.

The interesting thing is that even though they do provide automatic reconciliation, there is no guarantee about the referential integrity of the result. Two independent edits to two distinct key/values can always be merged; but they could easily break some external invariant which is not expressed explicitly.

What kinds of strategies should we then employ if we want to maintain integrity anyway, say for something simple like a one-to-may relationship?

http://www.javalimit.com/2011/01/understanding-vector-clocks.htmlErlang User of the Year 2010tag:typepad.com,2003:post-6a00d83455f7ed69e20133f615453a970b2010-11-19T12:09:09+01:002010-11-19T12:13:32+01:00At the Erlang User Conference in Stockholm, I received the thirteenth "Erlang User of the Year" award, and was presented with the traditional gift, a beautiful hand-carved Erlang logo made in wood by Kanevad in Gamla Linköping. I have to...Kresten Krab Thorup

At the Erlang User Conference in Stockholm, I received the thirteenth "Erlang User of the Year" award, and was presented with the traditional gift, a beautiful hand-carved Erlang logo made in wood by Kanevad in Gamla Linköping.

I have to admit that I did not even know this award existed, but I am honored to join the ranks of Chris Piro and Eugene Letuchy (Facebook chat, 2009), Damien Katz (CouchDB, 2008), John Hughes (QuickCheck, 2007), Alexey Shchepin (ejabberd, 2006), The HiPE team members 2005, Michaël Rémond (ejabberd, 2004).

The award is given by the Erlang community for technical contribution; in this case my work on Erjang - A JVM-based Erlang VM. I was quite surprised (pleasantly of course) by this since I am by no stretch an Erlang old-timer. I wrote my first line of Erlang code a little over a year ago during JAOO 2009 when Francesco Cesarini was giving an Erlang tutorial.

The Erjang project is doing really well. For many systems, Erjang is roughly twice as fast as Open Source Erlang (BEAM). Recently, we've been working on completing more of the core functionality, and we're already at a level where we can boot and run complex systems like Riak and RabbitMQ.

Since I did not really have time to prepare an acceptance speech, I'm sorry I did not get around to thanking all the people that have been supporting this project. Most importantly I should thank Erik Søe Sørensen, who was the first guy to stand up and contribute code to this lunatic project, my family (for living with my lunacy on a daily basis for a year now), and also the entire Erlang community for being surprisingly helpful and positive to this (literally) bastard project.

Once again, Thank you all!

Kresten Krab Thorup

http://www.javalimit.com/2010/11/erjang-receives-erlang-user-of-the-year-2010.htmlErjang - Interpreted Modetag:typepad.com,2003:post-6a00d83455f7ed69e20133f5972443970b2010-11-04T22:09:17+01:002010-11-04T22:11:57+01:00Erik has been hacking the interpreter the last few weeks, and now we're finally at a state where it is useful (though there are still some issues). ### Interpreter?? Yep, now Erjang has two modes of operations. - The default...Kresten Krab Thorup
<div xmlns="http://www.w3.org/1999/xhtml"><div style="float: right; margin-left: 1em"><script type="text/javascript">
var topsy_nick = "drkrab";
var topsy_style = "big";
</script>
<script type="text/javascript" src="http://cdn.topsy.com/button.js"></script></div>
<p>Erik has been hacking the interpreter the last few weeks, and now we're finally at a state where it is useful (though there are still some issues). </p>
<h3>Interpreter??</h3>
<p>Yep, now Erjang has two modes of operations. </p>
<ul>
<li>The default is the <em>Eager JIT</em> mode, meaning that modules are compiled from <code>.beam</code> to <code>.jar</code>-with-class-files eagerly as they are encountered as OTP boots up. This results in relatively slower start-up time, but fast execution.</li>
<li>The new option <code>ej +i</code> lets you run Erjang with the byte-code interpreter execution mode; which starts up faster, uses less memory, but runs slower.</li>
</ul>
<p>One effect of this can be seen from the launch time of Erjang. Look at this</p>
<pre><code>prompt$ rm .erj/* ## delete class cache
prompt$ echo 'erlang:halt().' | time ej
Eshell V5.8 (abort with ^G)
1&gt; 13.96 real 14.45 user 1.86 sys
</code></pre>
<p>Wow, that took 14 seconds to launch the Erjang REPL. Now, doing the same thing again should speed things up because now the <code>.beam</code> files have been compiled; see here:</p>
<pre><code>prompt$ echo 'erlang:halt().' | time ej
Eshell V5.8 (abort with ^G)
1&gt; 4.67 real 4.61 user 0.29 sys
</code></pre>
<p>Wow! the second launch was much faster because the <em>Eager JIT</em> does not have to pay the price of the up-front compilation.</p>
<p>So, running the interpreted Erjang (notice the <code>+i</code> there) gives you:</p>
<pre><code>prompt$ echo 'erlang:halt().' | time ej +i
Eshell V5.8 (abort with ^G)
1&gt; 2.47 real 2.64 user 0.20 sys
</code></pre>
<p>Wow, its only ~55% of the execution time. </p>
<p>You might be puzzled why this is faster than the pre-compiled case above. The reason is that Java byte code loading is fairly slow, and that case ends up loading a lot of java code. And the Java JIT has not yet had a chance to optimize the code.</p>
<p>Unfortunately, running BEAM (the <code>erl</code> command) yields...</p>
<pre><code>prompt$ echo 'erlang:halt().' | time ej +i
Eshell V5.8 (abort with ^G)
1&gt; 0.24 real 0.11 user 0.02 sys
</code></pre>
<p>10 times faster! Urgh. Fortunately for most erlang systems, launch time is not significant... but still. Over time (when the Java JIT kicks in) the performance of Erjang and BEAM are currently at-par.</p>
<h2>Memory Usage</h2>
<p>Having the interpreter provides two new interesting possibilities. First, it brings Erjang within reach of running on an Android machine, because (a) this execution mode does not involve runtime generation of code, and (b) the memory load is much smaller. Lets try to launch mnesia and inspect memory usage. see:</p>
<p>First, look at an interpreted mode...</p>
<pre>prompt$ ej +i
1> mnesia:start().
ok
2> 'java.lang.System':gc().
ok
3> erlang:system_info(allocated_areas).
[{'non_heap:CMS Perm Gen',134217728,10628584},
{'heap:CMS Old Gen',50331648,7618216},
{'heap:Par Survivor Space',1638400,0},
{'heap:Par Eden Space',13500416,1790200},
{'non_heap:Code Cache',2560000,2529664}]</pre>
<p>Next, compiled mode...</p>
<pre>prompt$ ej
Eshell V5.8 (abort with ^G)
1> mnesia:start().
ok
2> 'java.lang.System':gc().
ok
3> erlang:system_info(allocated_areas).
[{'non_heap:CMS Perm Gen',134217728,35051856},
{'heap:CMS Old Gen',50331648,13346696},
{'heap:Par Survivor Space',1638400,0},
{'heap:Par Eden Space',13500416,416592},
{'non_heap:Code Cache',2494464,2483520}]</pre>
<p>To make it more readable, here is a table ...</p>
<table>
<tr> <td> </td> <td> compiled</td> <td> interpreted </td> </tr>
<tr> <td> Old Gen</td> <td align=right> 13,346,696</td> <td align=right> 7,618,216 </td> </tr>
<tr> <td> Survivor Space</td> <td align=right> 0</td> <td align=right> 0 </td> </tr>
<tr> <td> Eden Space</td> <td align=right> 416,592</td> <td align=right> 1,790,200 </td> </tr>
<tr> <td> Perm Space (<i>Java byte code</i>)</td> <td align=right> 35,051,856</td> <td align=right> 10,628,584 </td> </tr>
<tr> <td> Code Cache (<i>native code</i>)</td> <td align=right> 2,483,520</td> <td align=right> 2,529,664 </td> </tr>
</table>
<p>With the compiled mode, memory adds up to ~55MB, in interpreted mode, ~20MB. Over time when the Java JIT kicks in, this difference is going to be even more evident.</p>
<p>Another interesting measure, is the memory usage before and after starting <code>mnesia</code>. With <code>ej +i</code> starting mnesia adds ~1MB total memory usage (similar to BEAM); but with compiled mode, starting mnesia adds ~9MB memory usage. So, while the baseline for a booted OTP is higher with Erjang <code>+i</code> than BEAM (~19MB vs ~3MB), the incremental memory usage when loading code and running is the same order of magnitude.</p>
<h3>HotSpot Erjang</h3>
<p>Another interesting potential would be to combine the Erjang interpreter an the Erjang JIT, so that code starts up interpreted and then if something is used "enough" it will get JIT'ed to java byte code. This is similar to how HotSpot Java does it (but is also one of the things that Oracle has patented and was recently suing Google over ...).</p>
<p>In such a scenario, there are some more interesting optimizations that would make sense; because if we have more information then it might well make sense to do more agressive optimizations and trade off some extra byte code generated for more speed.</p>
<h3>Getting there...</h3>
<p>As I hinted above, there are still issues with the interpreted mode; one is that interpreted mode uses more stack stack space; another is that there are some still some bugs lurking in there. At lease when running <code>rabbitmq</code>, something doesn't boot correctly. So, there is still some wat to go. </p>
</div>
<img src="//feeds.feedburner.com/~r/javalimit/~4/9IOpqEn2Qt4" height="1" width="1" alt=""/>http://www.javalimit.com/2010/11/erjang-interpreted.htmlGOTO Top 20 Talkstag:typepad.com,2003:post-6a00d83455f7ed69e20133f4faf032970b2010-10-11T12:02:03+02:002010-10-11T18:13:13+02:00Here's a quick tally of the top talks at last week's [GOTO Aarhus conference.](http://gotocon.com/aarhus-2010) The rating is based on the red, green and yellow "exit-poll", computed as (#green - #red) / #total votes. > Make sure to [evaluate the conference...Kresten Krab Thorup

Here's a quick tally of the top talks at last week's GOTO Aarhus conference. The rating is based on the red, green and yellow "exit-poll", computed as (#green - #red) / #total votes.

Mario's technical talk on ASP.NET MVC went straight to the top. Two people made it onto the list twice: Tim Bray and Brian Goetz. Gregor Hohpe who stepped in for a cancellation with a talk on Near Field Communication made #2.

Mind you, being #20 out of 84 talks is pretty good, and represents 83% approval.

Once again, we have talks from the so-called "vendor track" pop into the top talks; this. Jez Humble's and Arjen Poutsma's talks were very well received.

Personally, I'm sorry that I only made it to 5 of the talks on this list. With so much to choose from (and my various other obligations) it was hard to make it.

Over all distribution

The over all distribution of evaluations look like this, and I'm happy that 80 out of 84 talks total are above expectations. Great kudos to all the speakers and the program committee for making this happen!

As can be seen, four talks fell below expectations; and while that's obviously too many it gives us ideas for what to improve for next year's GOTO Aarhus. I think those bottom ones are one of two reasons: 1. misalignment of expectations, or 2. some speakers found it very difficult to present in the large room where it was difficult to interact with the audience.