Skip to content

In-memory job storage for Hangfire with transactional implementation

License

Unknown and 2 other licenses found

Licenses found

Unknown
LICENSE.md
GPL-3.0
COPYING
LGPL-3.0
COPYING.LESSER
Notifications You must be signed in to change notification settings

uzbekdev1/Hangfire.InMemory

 
 

Hangfire.InMemory

Build status perfvane

This is an attempt to create an efficient transactional in-memory storage for Hangfire with data structures close to their optimal representation. The result of this attempt should enable production-ready usage of this storage implementation and handle particular properties of in-memory processing like avoiding OutOfMemoryException at any cost and moderate load on garbage collection. Of course we can't avoid them entirely, but at least can control them somehow.

Read and write queries are processed by a single thread to avoid additional synchronization between threads and keep everything as simple as possible (keeping future async-based implementation in mind). Monitoring API also uses that dedicated thread, but its future implementation can be changed by using concurrent data structures and immutability, but I expect this will increase load on garbage collection.

Distributed locks (heh, in an in-process storage), queue fetch logic (even from multiple queues) and transactional queries are implemented as blocking operations, so there is no active polling in these cases. Every data returned by storage can be safely changed without causing underlying storage state to be changed with bypassing required transactional processing logic, so everything is safe (but increase load on GC). Every data structure, including indexes and their records, is removed when empty to avoid memory leaks.

TODO

  • Control OutOfMemoryException by providing some kind of limits which can be established easily, e.g. total number of jobs.
  • Avoid unnecessary object allocations without sacrificing the safety property (as described above).
  • Add integration (for public API) and unit tests (for internal API).
  • Force expiration when memory pressure is high to avoid OutOfMemoryException.
  • Add overridden default for expiration time for jobs and batches?
  • Can avoid synchronization in some read-only methods in the MemoryConnectionclass.
  • Avoid using large object heap at any cost by large collections – millions of jobs can be created.

Installation

Hangfire.InMemory is available on NuGet so we can install it as usual using your favorite package manager. Here is how *.csproj file look like when the package is installed to use the latest 0.X version.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Hangfire.InMemory" Version="0.*" />
  </ItemGroup>

</Project>

After the package is installed we can use the new UseMemoryStorage method for the IGlobalConfiguration interface to register the storage.

GlobalConfiguration.Configuration.UseInMemoryStorage();

About

In-memory job storage for Hangfire with transactional implementation

Resources

License

Unknown and 2 other licenses found

Licenses found

Unknown
LICENSE.md
GPL-3.0
COPYING
LGPL-3.0
COPYING.LESSER

Stars

Watchers

Forks

Packages

No packages published

Languages

  • C# 99.4%
  • Other 0.6%