jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com>
Subject Re: Design idea for a production-scale in-memory microkernel
Date Thu, 09 Aug 2012 16:00:32 GMT

On 8/7/12 10:12 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>On Tue, Aug 7, 2012 at 4:26 PM, Bart van der Schans
><b.vanderschans@onehippo.com> wrote:
>> I've thinking about similar in memory strategies ;-) Especially with
>> leveraging one of the existing in-memory data grid solutions
>> (hazelcast, infinispan, etc) which can take care of most of the
>> clustering details and the long term/backup/disk storage. I think this
>> is also what ModeShape 3.0 is doing with infinispan[1].
>Yep, both Hazelcast and Infinispan would be interesting alternatives
>as backends for such a microkernel.

Would this allow for a possibility of decreasing the cluster sync to the
point where a user who modifies data does not need to be bound to a
specific cluster node?

One problem that exists for write-oriented apps (user generated content)
is that as soon as a user needs to authenticate, if the auth token is
stored in content, that user must be bound to that cluster node.

Of course, the authentication problem could be fixed independently by not
storing the token in content, but the issues is the same when the user
makes any modification, and refreshes the view.

So, one option I am wondering about is the ability to:
- provide a memory store that has its own high speed clustering mechanism,
which can effectively avoid cluster sync delays
- provide a partitioning such that only editable parts of the content tree
rely on the memory store (e.g. Static assets of the site that never other
than via administrative content publishing can allow significant sync
delay - only the modifiable areas need improved sync performance)


>> But I guess
>> that would require a different architecture than is now implemented in
>> oak which has a more of a distributed (git like) structure with
>> options to scale (out) with sharding (I actually might be wrong on
>> this point since I'm not (yet) that familiar with the architecture).
>So far we've managed to keep the Oak architecture general enough to
>allow backends like the one outlined here.
>Jukka Zitting

View raw message