ledjon-behluli / orleanspaces

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

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

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

---

Documentation

• OrleanSpaces
• OrleanSpaces.Analyzers

---

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

Copyright © Ledjon Behluli

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.

Adjust OSA003 for System.Object[]

Adjust OSA003 to NOT report on direct array passing because of #6

Missing streamChannel write for BaseAgent

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...

Split 'SpaceOptions' into 'SpaceServerOptions' & 'SpaceClientOptions'

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

Agents missing rehydration upon startup

Agents must rehydrate their state upon startup, this is missing currently and needs to be resolved

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.

Add support for passing template to enumerable methods on the agent

• Enumerate(template = default)
• EnumerateAsync(template = default);

Both methods should enumerate only tuples that match the given template, or in cases when template = default, than it should enumerate all tuples in the respective space(s).

[Question] Do you use it in production?

Hi,

Is this project production ready?

Update documentation