Object store persistence

[Andrea Turli]

Hi,

I'm thinking about adding support to persist to generic object store. 

The basic idea is to use the jclouds blobStore abstraction and give users the ability to specify a `persistenceLocation` that can is a location spec, where they can specify the cloud provider they want to use. 

By default, If `persistenceLocation` is not specified the `persistenceDir` will be created on the local filesystem at the desired path (as it is now). If `persistenceLocation` is specified, `persistenceDir` will be used as relativePath inside the cloud providers (s3:/path/specified/by/persistenceDir), if available, otherwise the serialized brooklyn objects will be created in the root folder of the account.

Long-term, it would be nice to add a jsonSerializer to support nosql technologies that support only json documents.

Any thoughts?

Best,

Andrea 

[Alex Heneveld]

+1 -- this will be excellent

re syntax of `--persistenceLocation` are you thinking that's the same location spec strings we use elsewhere (e.g. named location or jclouds name):

    --persistenceLocation jclouds:aws-ec2

that is nice and simple.  although this will need extending again to support platforms such as mongo or riak or couchbase, i think that's fair.

re default path in cloud providers, i'm not a fan of putting everything in the root!  `PERSISTENCE_DIR` currently defaults to `brooklyn-persisted-state/data`, see `BrooklynServerConfig.getPersistenceDir()`; we could use that.  (however the method `getPersistenceDir()` will need refactoring to take a cloud location so that it can tell whether it should be `relativeToBase` (ie no location) or absolute (in a blobstore or other document store).

best
alex

--
You received this message because you are subscribed to the Google Groups "brooklyn-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Harris]

How frequently is the object store written to / read from?

--

You received this message because you are subscribed to the Google Groups "brooklyn-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Martin Harris

Lead Software Engineer

Cloudsoft Corporation Ltd

www.cloudsoftcorp.com

Mobile: +44 (0)7989 047-855

[Andrea Turli]

Hi Martin,

for example, HighAvailabilityManagerImpl has a pollingTask that polls every 5 seconds by default, so I think this will be the read frequency.

Does it answer your question?

Andrea

[Aled Sage]

Hi Andrea,

The other time that affects write-frequency is in RebindManagerImpl.periodicPersistPeriod. This is the major one as it affects the maximum frequency that (changed) entities/locations will be persisted.

---
For some code pointers into hooking in the blob-store persistence...

See BrooklynMementoPersisterToMultiFile for where we control writing to and reading from the file system.
I suspect this could be generalised so that it isn't just about files.

It delegates to... MementoFileWriter. This is the file-specific piece that you'd want to replace. However, it also includes generic logic to handle concurrency: if asked to write,write,write then it handles queuing up these writes and discarding the middle write if the new request comes in before the middle one has started (etc). It also handles concurrent calls to write/delete to ensure that the last-update wins.

---
Rather than completely duplicating these classes, it's probably worth starting with an interface such as:

public interface ObjectStore {
    public interface ObjectAccessor<T> {
        void writeAsync(T val);
        void deleteAsync();
        T read();
    }

    /**
     * For reading/writing data to the given path.
     * For example, if a file-based ObjectStore is configured to write to file://path/to/root/
     * then subPath=abc would read/write data to file://path/to/root/abc
     */
    ObjectAccessor newAccessor(String subPath);
       
    /**
     * Lists the paths of objects contained at the given path.
     * For example, if a file-based ObjectStore is configured to write to file://path/to/root/
     * then parentSubPath=entities would return the contents of /path/to/root/entities/, such as
     * [entities/e1, entities/e2, entities/e3].
     * The returned paths values are usable in calls to {@link #newAccessor(String)}.
     */
    List<String> listContents(String parentSubPath);

    /**
     * Makes a copy of all objects under parentSubPath.
     * For example, if a file-based ObjectStore is configured to write to file://path/to/root/
     * then parentSubPath="abc", backupSubPath="abc.bak" would be the same as:
     * `cp -R /path/to/root/abc/* /path/to/root/abc.bak/`
     */
    void backupContents(String parentSubPath, backupSubPath);

    /**
     * Closes all resources used by this ObjectStore. No subsequent calls should be made to the ObjectStore;
     * behaviour of such calls is undefined but likely to throw exceptions.
     */
    void close();
}

The BrooklynMementoPersisterToMultiFile could then be refactored to use this, and the existing file-based code refactored to implement that interface.

Does that make sense to you?

Thoughts?

Aled