5 ms·

Has this been done by someone? I remember the same answer (use Clojure + Terracotta) being given months ago when someone in the clojure google group asked for e

by kanak 16y ago

Has this been done by someone? I remember the same answer (use Clojure + Terracotta) being given months ago when someone in the clojure google group asked for erlang type distribution support. I was wondering if someone had actually done it to see how well it works.

bnoordhuis 16y ago
I can answer this question for Java + Terracotta. Terracotta works much of its magic through bytecode instrumentation so I expect that the differences between Clojure and Java are minimal. Pros: 1. Makes it very easy to turn an existing threaded application into a multi-node application, often no code changes required. Killer feature. 2. Integrates seamlessly with Spring and Ehcache. Perhaps less relevant for Clojure developers but a big boon for JEE people. Cons: 1. It uses multicast for replication. This is an implementation detail, not a conceptual drawback, but it's a pain to set up when your machines live in different network segments. 2. Can potentially transmit stupid amounts of data over the wire. I suppose this is part design, part configuration.
- JulianMorrison 16y ago
  If you are going to use Terracotta you really do need to design for it - even if it could in theory wrap a naive design, you'll probably thrash the network. Some ideas for Terracotta friendly design I can think of, right off the bat: 1. If this node is the only one using this particular shared data structure right now, it gets to operate locally without network transactions until it's done. 2. If you consistently use a small part of a large data structure (eg: a hash), you'll only have that small part "paged in" on that one node. The whole data structure can be larger than RAM. Thus, node affinity can be important. 3. Be careful how much work is done inside a synchronized method of a shared data structure. It should be a medium amount. Too much, and you'll make other users wait, too little and you'll thrash the network.

by kanak 16y ago

bnoordhuis 16y ago

I can answer this question for Java + Terracotta. Terracotta works much of its magic through bytecode instrumentation so I expect that the differences between Clojure and Java are minimal. Pros: 1. Makes it very easy to turn an existing threaded application into a multi-node application, often no code changes required. Killer feature. 2. Integrates seamlessly with Spring and Ehcache. Perhaps less relevant for Clojure developers but a big boon for JEE people. Cons: 1. It uses multicast for replication. This is an implementation detail, not a conceptual drawback, but it's a pain to set up when your machines live in different network segments. 2. Can potentially transmit stupid amounts of data over the wire. I suppose this is part design, part configuration.

JulianMorrison 16y ago
If you are going to use Terracotta you really do need to design for it - even if it could in theory wrap a naive design, you'll probably thrash the network. Some ideas for Terracotta friendly design I can think of, right off the bat: 1. If this node is the only one using this particular shared data structure right now, it gets to operate locally without network transactions until it's done. 2. If you consistently use a small part of a large data structure (eg: a hash), you'll only have that small part "paged in" on that one node. The whole data structure can be larger than RAM. Thus, node affinity can be important. 3. Be careful how much work is done inside a synchronized method of a shared data structure. It should be a medium amount. Too much, and you'll make other users wait, too little and you'll thrash the network.