work there.
Yes, I can try to help. Feel free to write me.
Actually, I would like to try Clojure + Terracotta as a data layer for
my Java app, so I'm more interested in adapting the changes to the
latest Clojure codebase and tuning Terracotta interaction. I saw
autolocking in config an
Thanks for your feedback.
I was able to get it to work again and pushed some minor changes to
the git repo. I downloaded Terracotta 3.1.1, and followed the
instructions in the tim-clojure-1.0-SNAPSHOT/example/README. I ended
up uncommenting all of the code in ClojureTerracottaConfigurator.java.
I
Hi Paul,
the code from [1] does not work under the latest Terracotta (3.1.1)
with clojure-slim.jar's in the following combinations:
1) branch "1.0.x" from [3]
2) branch "1.0.x" from [3] + modified
ClojureTerracottaConfigurator.java (uncommented lines)
3) [2] svn revision 1335 + modified ClojureTe
Thanks for your answer, Paul!
I'm certainly going to try this TIM.
Another question:
You say that "it requires runtime replacement of some Clojure classes"
but the lines that include modified *TC.java files are commented ( see
"ClojureTerracottaConfigurator.java" from "tim-clojure-1.0-snapshot"
Sorry! I forgot to say this, but the short answer is: No, I would not
consider it to be production ready. It may be close, but it is not
production ready.
Paul
On Sun, Nov 15, 2009 at 2:47 PM, Sergey Didenko wrote:
> Hi from a Clojure newbie!
>
> I have read the april thread
l
[1] http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv
[2] http://paul.stadig.name/2009/04/terracotta-bug-reports.html
On Sun, Nov 15, 2009 at 2:47 PM, Sergey Didenko wrote:
> Hi from a Clojure newbie!
>
> I have read the april thread "Clojure + Terracotta Update" and it
&g
Hi from a Clojure newbie!
I have read the april thread "Clojure + Terracotta Update" and it
looks pretty positive.
A few question for TIM users:
Is there newer version than
http://github.com/pjstadig/tim-clojure-1.0-snapshot ?
Are there still bugs?
Can it be called production ready
t; On Mon, Mar 30, 2009 at 7:38 PM, Rich Hickey wrote:
>
>>
>>
>>
>> On Mar 30, 5:12 pm, Paul Stadig wrote:
>> > I have gotten to the point in my Clojure + Terracotta experiment, where
>> I
>> > believe all of the features of Clojure are function
ter
On Mon, Mar 30, 2009 at 7:38 PM, Rich Hickey wrote:
>
>
>
> On Mar 30, 5:12 pm, Paul Stadig wrote:
> > I have gotten to the point in my Clojure + Terracotta experiment, where I
> > believe all of the features of Clojure are functional (Refs, Atoms,
> > transacti
On Mar 30, 5:12 pm, Paul Stadig wrote:
> I have gotten to the point in my Clojure + Terracotta experiment, where I
> believe all of the features of Clojure are functional (Refs, Atoms,
> transactions, etc.). I do not have a way to extensively test the Clojure
> functionality, bu
I have gotten to the point in my Clojure + Terracotta experiment, where I
believe all of the features of Clojure are functional (Refs, Atoms,
transactions, etc.). I do not have a way to extensively test the Clojure
functionality, but I have run the clojure.contrib.test-clojure test suites
On Mar 5, 4:23 pm, Paul Stadig wrote:
> I had one last, major hurdle, and was helped by Chouser (thank you!).
>
> http://paul.stadig.name/2009/03/clojure-terracotta-we-have-repl.html
>
> Still lots more to do, and probably some simple changes that could be
> rolled bac
On Mar 5, 12:23 pm, Paul Stadig wrote:
> I had one last, major hurdle, and was helped by Chouser (thank you!).
>
> http://paul.stadig.name/2009/03/clojure-terracotta-we-have-repl.html
>
> Still lots more to do, and probably some simple changes that could be
> rolled bac
awesome Paul :)
On Thu, Mar 5, 2009 at 12:23 PM, Paul Stadig wrote:
>
> I had one last, major hurdle, and was helped by Chouser (thank you!).
>
> http://paul.stadig.name/2009/03/clojure-terracotta-we-have-repl.html
>
> Still lots more to do, and probably some simple cha
I had one last, major hurdle, and was helped by Chouser (thank you!).
http://paul.stadig.name/2009/03/clojure-terracotta-we-have-repl.html
Still lots more to do, and probably some simple changes that could be
rolled back into the Clojure codebase. However, I feel as though I've
finally re
I've done some more work on Clojure + Terracotta. I moved my code into
a Terracotta Integration Module (TIM), which allows the bundling and
reuse of the Terracotta configuration, but also provides for class
replacement so that clustered versions of some classes can be written
without necess
ote:
>
> > We will go for a TIM. Just looked at the doc and tes that would simplify
> > our work a lot.
>
> > Thank you,
>
> > Luc
>
> > On Sat, 2009-02-28 at 18:48 -0800, Nabib El-Rahman wrote:
> > > Hi guys,
>
> > > I work for Terraco
is).
> We're having a clojure user-group meeting on the 12th of March - and
> the clojure/terracotta topic is of interest to a lot of people...
> It would be wonderful if someone would come and talk about the
> progress...
>
> Regards,
> Amit.
>
> http://www.meet
t; Are any of the folks on this thread in/around the bay area? (I know
> Nabib is).
> We're having a clojure user-group meeting on the 12th of March - and
> the clojure/terracotta topic is of interest to a lot of people...
> It would be wonderful if someone would come and talk about
Are any of the folks on this thread in/around the bay area? (I know
Nabib is).
We're having a clojure user-group meeting on the 12th of March - and
the clojure/terracotta topic is of interest to a lot of people...
It would be wonderful if someone would come and talk about the
progress...
Re
We will go for a TIM. Just looked at the doc and tes that would simplify
our work a lot.
Thank you,
Luc
On Sat, 2009-02-28 at 18:48 -0800, Nabib El-Rahman wrote:
> Hi guys,
>
> I work for Terracotta ( on the server side ) and find this work with
> Clojure + Terracotta very exciti
I've started work on a Terracotta Integration Module for Clojure
already. As I understand it, we can package up the Terracotta config
as well as any replacement classes. This way we can "patch" Clojure
temporarily until either Terracotta supports the features we need, or
Clojure can be rewritten s
Its a way to package integration details into a module. For example, if I
want to cluster EHCache, I can drive through the code and figure out what
data structure to share and subsequently lock on. All that work can be
packaged into a module for terracotta, so that way people who just want to
use
>
>
> Writing a TIM is definitely the way to go, It's a place to hide the glue
> until both Terracotta and Clojure catches up with each other.
uhhh what is a TIM?
Thanks
Hank
--
blog: whydoeseverythingsuck.com
--~--~-~--~~~---~--~~
You received this m
Hi guys,
I work for Terracotta ( on the server side ) and find this work with Clojure
+ Terracotta very exciting. Writing a TIM is definitely the way to go, It's
a place to hide the glue until both Terracotta and Clojure catches up with
each other. If you have any questions feel free to po
We think the same way. Our first implementation of an alternative to
AtomicReference
is straightforward, we will look at improving it if the need arises.
It will be easier to do so when we get stats from Terracotta after
running some benchmarks.
There's much to do before getting there.
Luc
On S
In the Namespace case, it might be premature optimization to worry
about AtomicReference being replaced. If there is a way to rewrite
that code with, say, synchronized blocks, and it will work better with
Terracotta, I think it would be worth doing. I don't think it would be
normal usage to be upd
1) AtomicReference is used in several places. Instead of changing it, we
think we can keep
it when Clojure runs "locally" and provide an alternative when running
in "shared" mode.
AtomicReference is optimized to be efficient in a standalone JVM. We
would like to
keep it that way. Eventually Terra
My approach was just to share what few refs I wanted, but another
approach (like Luc's) is to share everything. The obvious advantage
being that you can set! the root binding of vars (like function
definitions). The goal with Terracotta is to make things as
transparent as possible, so I don't thin
; > > 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" imp
nt 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
; 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
> 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 experimenta
Paul Stadig writes:
> 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
Very exciting; I'm looking forward to trying this out!
ure 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
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
On Oct 20, 10:12 am, Alex Miller <[EMAIL PROTECTED]> wrote:
> Sorry, I was not thinking straight when I wrote part of this. We will
> protect you from seeing nulls by faulting values back in, even if not
> read under a lock. So, what you said originally there is true. There
> is a possibility
Sorry, I was not thinking straight when I wrote part of this. We will
protect you from seeing nulls by faulting values back in, even if not
read under a lock. So, what you said originally there is true. There
is a possibility that you can get dirty reads in this scenario but in
the case of an i
Rich, I'm the tech lead for the transparency team at Terracotta and
this is not exactly correct. For example, while you can read
clustered state outside of a clustered lock, it's possible for the tc
memory manager to clear that state at any time, allowing you to see a
null instead of the real val
Ok, I'll digest this in the next couple of weeks and have a look more
closely
at Clojure code and Terracotta's capabilities.
I have a non-linear thinking process so it helps to have some early
goals.
I'll create some prototype setup here to help identify issues and run
some basic tests.
Thank you
On Fri, Oct 17, 2008 at 8:01 PM, Luc Prefontaine
<[EMAIL PROTECTED]> wrote:
> I am not very far from tackling this issue. In our bus messaging system, we
> are using Terracotta with some Java components
> and it's a matter of weeks before we start to investigate how we can bridge
> Clojure and Ter
41 matches
Mail list logo
