jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: [jr3] Clustering: Scalable Writes / Asynchronous Change Merging
Date Thu, 21 Oct 2010 19:03:02 GMT

> Network delay .. is faster than the delay of a disk

I wrote ""the network is the new disk" (in terms of bottleneck, in
terms of performance problem)". Network delay may be a bit faster now
than disk access. But it's *still* a huge bottleneck (compared to
in-memory operations), specially if cluster nodes are far apart. If
you have the complete repository in-memory, but for each operation you
need network access, then the network is the bottleneck. And I don't
want that to be the bottleneck. I know I repeat myself, but it looks
like this was not clear.

> importance of leveraging in-memory storage

In-memory storage *alone* is fast. But if used in combination with the
current clustering architecture, then writes will not scale. They will
be just be a bit faster (until you reach the network delay wall).

> What is then the reason for asynchronous change merging, if not for
> performance?

Where did I say it's not about performance? As I already wrote: "it's
about how to manage cluster nodes that are relatively far apart."

> observation listeners would not always get notified in the same order

Regular observation listeners are not necessarily the problem, we
could just delay them until the pre-defined sync delay (until things
are in sync). The problem are *synchronous* event listeners (as I
already wrote). The JCR API doesn't actually define them as far as I


View raw message