Monads in GridGain: Basics of FP

Monadic operations play a central role in GridGain APIs. So, what is a monad?

One of the best down-to-earth definition of monadic operation is that it is simply a design pattern, a pipeline of function calls defined on an arbitrary set of types. An object that exposes such behavior called monad.

We have monads in Java too. Think of Iterable interface. It defines a monadic operation (i.e. iterator) that is defined for a wide variety of classes (and even some special cases like arrays). Method toString() is another example of a monadic operation. You can ask: what is the difference between a simple interface and monad operations? The answer is: in Java – there’s almost no difference, but in other languages like Scala or Haskel the difference can be that monads do not require an interface and are more powerful concepts because of it.

Back in GridGin 3.0 we have two central concepts in our APIs:

  • GridProjection
  • GridCacheProjection

GridProjection defines a monadic set of operations defined on any arbitrary set of grid nodes. In fact, Grid, GridRichNode and GridRichCloud all implement GridProjection interface and are monadic projections. Grid defines a projection on all nodes in global topology, GridRichNode defines a projection with only one node in it, and GridRichCloud defines a projection for all nodes in the given cloud.

Correspondingly, GridCacheProjection defines a set of monadic operations on any arbitrary set of cache entries (keys, values, or key-value pairs to be specific).

These two concepts give enormous elegancy to our APIs while not making them unnecessary complex. Let me give you couple of examples so that all that would make more sense.

In GridGain 3.0 you can create a dynamic grid projection with a predicate that says that this projection should contain any nodes that, let say, have a specific attribute. Once you have such projection you can now execute closures or tasks on it, send and listen for messages, or do dozens upon dozens of other operations. Now, since this is a dynamic projection any new node joining the grid with a given attribute set will be automatically added to the projection (and vice versa – if a node from this projection leaves the topology it will leave the projection too). This gives you very elegant approach on how to isolate yourself from any changes in cloud topology (example in Java):

GridProjection p = G.grid().projection(new PN() {
	public boolean apply(GridRichNode node) {
		return node.getAttribute(“foobar”) != null;


In this example, if projection becomes empty (no nodes in it) – execute(…) operation will rightfully throw an exception.

There are plenty operations to manage projections: you can cross or merge projections, you can examine their size, see if they are empty or dynamic, get a predicate for the projection, and most of the operations on the projection support additional filtering predicates.

Here’s another example with cache projection.

Let’s create cache projection that would filter out any values greater than 10. To do that we create dynamic cache projection with a predicate and since cache projection defines over 95% of all operations available on cache – we can use it directly as named cache instance (example using Scalar – Scala-based DSL for GridGain).

scalar {
    val c = cache[String, Int] ~/ ((e: GridCacheEntry[String, Int]) => e.peek() > 10)
    c += "1" -> 1 // That won't be added since value below 10
    c += "1" -> 11 // That will work ok!

Now, since predicate can have any logic in it it gives you nice and elegant way to limit or constraint your cache for your specific purposes – yet it doesn’t require any additional APIs on the cache itself. For example, you can create strongly typed projection by specifying the types of keys and values:

scalar {
    val c = cache ~| (classOf[String], classOf[String])

    c += ("skey" -> "sval") // That compiles ok.
    c += ("s" -> 2) // That WON'T compile since 2 is not a String.

These examples show just the trivial usage of monadic operations in GridGain. In real applications their usage results in a concise and powerful usage pattern that minimize your code – yet gives it clarity and easier readability.


JavaOne 2010: Learn About GridGain 3.0 Java-based FP Story


I’ll be speaking at JavaOne 2010 on Monday, September 20th and this is going to be an unusual talk: I’m not going to speak about GridGain per-se, but about the journey that led us to introducing Functional Programming (FP) into GridGain 3.0 and the lessons we’ve learned along the way.

One of the most intriguing things you will learn is the best way to provide similar functionality to Scala’s Option or Haskel’s Maybe – but in Java without implementing a single class… And you will be surprised by just how elegantly you can do that in Java!

Stay tuned and make sure to stop by my presentation at JavaOne 2010.

JavaZone 2010: Excellent as Always

I usually don’t write just about the experience of conference. But for some reasons I really like JavaZone conference… I’ve spoken there couple of times and every time it stands out from the rest. Is it a band, or stadium venue, or excellent equipment, or sheer number of people that is attending it – don’t know. But every conference we have back in states, including TSSJS and JavaHome, just looks boring and pedestrian in comparison.

Plenty of good sessions too. I’ve listened to couple of Scala ones – and really liked Jones Boner’s one on Akka. I’ve heard the same presentation before and I was looking how Jonas will fit plenty of content in just 60 minutes. It came out all right to my ear but you needed to follow up closely as Akka stuff is not that obvious.

Few quirks – as always.

Evening session drew significantly less people on second and third days and that’s unfortunate as there were plenty of excellent talks – but folks got really tired by then.

If you are the speaker – you must not have a fear of height as you are to present from the small platform hoisted by cables at 4 story building height! That threw me off initially and I was really surprised there were no accidents as even the stairs were extremely steep.

Finding the entrance for the “room” (nothing more than a section of the stadium separated by the drapes) was a challenge on its own initially. There were no clear marks (or no marks at all) – but if you found it once you usually can find it again.

Abundance of consulting shops on the exhibit floor is about the only downside of this conference. I understand they need to hire and attract people – but there is got be at least couple of actual software development companies in Scandinavia. In the sea of body-shops – it was hard to find one.

All in all – an excellent conference and is highly recommended as always.

Last but not the least – Scandinavian’s herring dishes are something else. I wish I could bring this back to states but I’m sure customs will partake it.

How Do I Start with GridGain?

I’ve met yesterday with one or our clients and a good question came up: given the size and sheer volume of features in GridGain 3.0 how do we start and where do we start with GridGain?

In thick of a mad rush to push the release of GridGain 3.0 it is easy to be blind folded of just how much GridGain grew in functionality and how it is unsettling for someone new looking from outside in to find a starting point in using GridGain…

So the answer is: don’t start BIG.

GridGain is similar to Spring in this regard: although Spring has large number of projects in its portfolio – most people start with Spring IoC/DI container and general Spring wrappers, and then move on as they need.

The same is with GridGain. You can start with our new Actor-based messaging in 3.0 or simply piggy back on our automatic discovery and topology management. Many clients used GridGain as a better alternative to Java’s RMI – and there’s nothing wrong with that too.

I have always been saying that one of the most elegant use of GridGain is to use standard Java executor service backed by GridGain (just call executor() on grid projection). This basically gives you a standard bottom-less grid-wide thread pool. Nothing can be easier – just one extra line of code to get the thread pool.

So, the best way to use GridGain: start small, see what features make sense for you and then dig deeper to optimize your use case. GridGain is an excellent tool that will grow with you…