We are trying to get Clojure shared over Terracotta, not just specific
things but the whole Clojure object space
(name spaces, root values, ....) except stuff that needs to remain local
(streams, ....).

We take an all or nothing approach here, we would to see many Clojure
instances work as a single
entity.

We are facing a number of issues, one of them being the lack of support
by Terracotta of AtomicReference.

Terracotta has placed this class in the list of classes they will
eventually support but has of 2.7.3
it's still not supported.

The Sun AtomicReference does peeks and pokes in the heap using internal
routines of the JVM (JNI).
Clearly this cannot be done with multiple JVMs, different object
heaps, ....

Terracotta suggest using the oswego library but since Java 5 has been
out, it's in maintenance mode only and 
integrating another library to the puzzle for that single purpose did
not look to us as very efficient.

So we created a SharedAtomicReference implementation that uses standard
locks to control access to
the value with the corresponding Terracotta configuration.

We use a factory to decide at run time which implementation to use based
on a system property.
To preserve the Clojure code base, we implemented an AtomicReference
interface and a delegate to
the AtomicReference class. The Clojure code uses now  interface. 
This allows us to make progress without disturbing the Clojure code base
too much.

This has some performance implications that we do not fully understand
yet since we need a living Clojure implementation
to work with, something we are in the process of creating... what a
catch 22 :)))
We thought about spending time working on this aspect right now but we
prefer to wait for the first alpha release.

As for the rest of the Clojure code, we are working on the classes
implementing vectors, hash maps, ....
to get them shared through terracotta.

Our main challenge these days is putting together the terracotta
configuration of the internal classes of Clojure that need to be shared.

We may hit issues that make some classes non portable. 
These will require us to implement an alternative.  We will use then a
slightly different approach,
we need only factories to allocate an alternate version or the "local"
implementation.
The Clojure code already uses interfaces to access the data objects so
this will be almost transparent in the code.

We prefer to re implement an "distributed" implementation side by side
with the original one and easily switch between them
to compare behaviour and performance with the same code base.

When we have a clearer understanding of how it performs we will look at
how to merge this in the code base
that will have changed in between. We may be able then to reduce the
number of alternate implementations
if more where created.

The work is in progress, next week is a school break week here so the
pace will slow down a bit.
We wanted to start earlier on this (before XMas) but we had updates to
put in production , client caring to do, ...
and other mundane tasks to get the bread and butter on the table.

Comments/suggestions are welcomed...

Luc


On Fri, 2009-02-27 at 12:20 -0800, Paul Stadig wrote:

> I've recently done some experimentation with Clojure and Terracotta.
> I've detailed my experience at:
> 
> http://paul.stadig.name/2009/02/clojure-terracotta-yeah-baby.html
> 
> and shared my code at:
> 
> http://github.com/pjstadig/terraclojure/tree/master/
> 
> I'm the first to admit that I'm not an expert in Terracotta. This is
> actually my first time working with it.
> 
> I was able to setup a permanent store, and to run a couple of
> transactions against some refs shared across multiple JVMs. I ran into
> two snags. The first was that Keyword did not implement hashCode,
> which was a simple fix. Rich graciously added a hashCode method. :)
> 
> The other was how to point Terracotta to a var from the Java side. I
> ended up using a simple Java class to hold on to my refs, since then
> it was easy to point Terracotta to the right place. It works just
> fine, but I'm not sure if there is a better way to do it.
> 
> I'd be interested in knowing if anyone else has experience to share
> about using Terracotta with Clojure.
> 
> 
> Paul Stadig
> 
> > 
> 

-- 

Luc Préfontaine

Off.:(514) 993-0320
Fax.:(514) 993-0325

Armageddon was yesterday, today we have a real problem...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to