GithubHelp home page GithubHelp logo

ledjon-behluli / orleanspaces Goto Github PK

View Code? Open in Web Editor NEW
58.0 4.0 3.0 2.39 MB

A virtual, fully-asynchronous, Tuple Space implementation backed by Orleans.

License: Apache License 2.0

C# 99.60% PowerShell 0.40%
orleans dotnet concurrent-programming distributed-computing tuple-space sba

orleanspaces's Introduction

OrleanSpaces

OrleanSpaces

Tuple space is an implementation of the associative memory paradigm for distributed computing. It provides a repository of tuples that can be accessed concurrently.

Orleans is a framework that provides a straight-forward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.

OrleanSpaces is a package that brings the power of the tuple space programming model into the .NET world, by using Orleans as the backbone.

Why virtual?

Much the same way as actors in Orleans, the tuple space in OrleanSpaces can't be explicitly created or destroyed, it always exists, virtually! Its existence transcends the lifetime of any of its in-memory instantiations, and thus the lifetime of any particular server. This alleviates the developer from a lot of ceremonial/infrastructural work that would have been neccessary.

Why fully-asynchronous?

The IN and RD operations in the tuple space paradigm, are inherently blocking operations. If there is no matching tuple found in the space, then the process which has called these operations, has to wait until it gets a matching tuple. This, intrinsically has an impact on the general availability of the whole system. In OrleanSpaces these operations are done in a fully-asynchronous way, via callback channels.

When I say that IN and RD are implemented in a fully-asynchronous way, I am not referring to the non-blocking versions INP and RDP! These are sepparate concepts, which by the way are also implemented in OrleanSpaces.

Motivation

While the tuple space paradigm offers unparalled computing capabilities, it is quite the feat to get it right! A proper implementation ideally should support capabilities like:

  • Scalability
  • Availability
  • Resiliency
  • Persistence
  • Transactions
  • Concurrency
  • Location transparancy

Hobby implementations of the tuple space fail to deliver on a lot of those, and while enterprise solutions (JavaSpaces, GigaSpaces, IBM TSpaces, etc.) do a better job at it, they usually come with a price, and put the burden of managing the spaces' state to the developer.

All of the above-mentioned capabilities come out-of-the-box with Orleans. The idea was not to reinvent the wheel, but instead leverage Orleans, while providing an abstraction to the client, and build features upon it.

Packages

CI

Package Description NuGet Version Test Coverage
OrleanSpaces Main library. nuget coverage
OrleanSpaces.Analyzers Code analysis and fixes for OrleanSpaces. nuget coverage

Documentation


If you find it helpful, please consider giving it a ⭐ and share it!

Copyright © Ledjon Behluli

orleanspaces's People

Contributors

ledjon-behluli avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

orleanspaces's Issues

Enhance 'AddOrleanSpace()' on the silo builder

Enhance 'AddOrleanSpace()' on the silo builder by means of accepting 2 optional options configs.

  public static ISiloBuilder AddOrleanSpaces(
      this ISiloBuilder builder,
      Action<SpaceServerOptions>? configureServerOptions = null,
      Action<SpaceClientOptions>? configureClientOptions = null)
{
...
}

If user provides an non-null configureClientOptions and specifies SpaceKind.XXX then that space (therefor also the agent) is available in the silo too.

Concurrent sample: intermittent failure

In SpaceTuple.cs, I modified to avoid crash:

public override string ToString() => fields == null ? "!! fields is null !!" : $"({string.Join(", ", fields)})";

Run Concurrent:

...
READER 0: (exchange-key, 0)
READER 4: !! fields is null !!
READER 6: (exchange-key, 6)
...

Usually 1 or two Readers have null fields.

Allow configurability on the space loading process for agent(s)

In certain cases like where the agent is used to perform only writes, or the application needs fast startup times, it is useful to allow a configurable way to load (or not) the space contents. Best way is to have this on the SpaceOptions.

The functionality needs to be complimented via a new method on the ISpaceAgent (and generic versions) called ReloadAsync which acts as loading the space for agents that have been configured to NOT load space upon startup, or in general a reload of the space (for whatever reasons)

Implement space partitioning

Partitioning the space for each space kind allows us to avoid performance impacts due to frequent updates to a large list of tuples, because each update involves serializing and persisting the entire dataset.

Change agent signature to reflect in-memory data locality

  • ValueTask CountAsync() -> int Count {get;}
  • ValueTask : PeekAsync(template) -> tuple : Peek(template)
  • ValueTask<IEnumerable> : ScanAsync(template) -> IEnumerable : Enumerate(template)
  • IAsyncEnumerablePeekAsync() -> IAsyncEnumerableEnumerateAsync()

Create OSA004

  • Create new analyzer that detects usages of generic tuples & templates that should be specialized ones.
  • Create associated fixer that converts i.e:
    SpaceTuple(1, 1, 1) -> IntTuple(1, 1, 1)
    SpaceTuple('a', 'b', 'c') -> CharTuple('a', 'b', 'c')
    etc...

Allow passing object[] directly to ctor of SpaceTuple & SpaceTemplate

Makes it more feasible to work with the generic tuples as a whole array can be passed as opposed to array elements.
This is useful when clients build an array of elements in a loop and want to pass it down, or if they already get an array from a source that they can not control

Startup loading behavior batch vs all

While getting all data collected from the director grain is the more efficient way, since it involves n + 1 calls, where n is the number of
partitions (i.e. store grains), and 1 is a call from the agent to the director, and all calls to the store grains are done in parallel via Task.WhenAll. We need to keep in-mind the potential size of the whole tuple space, so when the number of partitions grows a lot, this call to the director might result in contention for ThreadPool threads and may lead to thread starvation, therefor degrading performance.

An alternative is for the director to expose an IAsyncEnumerable way to load the data, where each call to it will result in a single batch of loading the data. This "batch" basically means the director calls the store grains one-by-one and streams back the result which the agent call append to its in-memory dataset. This does result in a slower loading of the whole tuple space, as there are 2*n calls, each time a call to the director + 1 call to the partition of a store, but ultimately should not lead to potential thread starvation.

We should have a configurable behavior for this in the SpaceClientOptions.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.