[][src]Crate jupiter

Jupiter is a library for providing high throughput ultra low latency services via the RESP protocol as defined by Redis.


Jupiter is a framework for wrapping compute or memory intense components to provide them as high throughput and ultra low latency services to applications built on managed runtimes like node.js, Java, Ruby.

These managed runtimes are great for building sophisticated web applications but have limited capabilities when raw compute power or optimized memory utilization is required. This on the other hand is an area where Rust shines, as it permits to write low-level and highly optimized code which is still safe to run.

Therefore all we need is a simple an efficient way of combining the best of both worlds. To minimize the overhead of communication, we use the RESP Protocol as defined by Redis. In contrast to HTTP this is way simpler to parse and handle while also supporting zero-copy operations. Another benefit is, that for nearly every platform there is already a Redis/RESP client available.


We at scireum use Jupiter in conjunction with our open source Java framework SIRIUS to build web based applications.

We use Jupiter as an LRU cache for intermediate search results and search metadata. We also store large parts of semi-constant masterdata (think of "all ZIP codes and street names in germany) there. Both of these frameworks are contributed to the open source community and can be either used in own applications or directly by running a Jupiter IO instance.

Our most central use of this framework lies in Quasar which sadly has to remain closed source. This application contains our complete text processing framework which runs everything from syntactical pre-processing to full morphological analysis steps in order to maintain our excellent search experience in our products.


  • Ultra fast non allocating parser for RESP queries (as sent by redis-cli and redis clients). The built-in server will use a single buffer per connection to read, parse and process queries. To deliver a response, a single buffer is allocated to buffer the response to minimize the number of required sys-calls to write a response on the wire.
  • 100% Async/Await - the whole server builds upon tokio and async/await primitives as provided by Rust. Also, all commands handlers are build as actors to simplify concurrency correctness and to also minimize any synchronization overheads.
  • Reload-aware config facility which permits to update the configuration during operation. Therefore no restart is ever required, even when changing the IP binding or port. This is kind of important for a in-memory application which might have an expensive startup time.
  • Build in management commands. The core module provides a set of management commands to monitor and inspect the state of the system.
  • Simple and well documented code base. After all, Jupiter isn't a large framework at all. This permits every user to browse and understand its source code and when to expect from the system. Also this is due to the fact that Jupiter stands on the shoulders of giants (especially tokio).


A complete example of using Jupiter can be found here: Jupiter IO.

Still a short example on how to initialize the library can be found here Builder. A super simple command can be found in the implementation of ping. A more sophisticated example would be core.

Using Jupiter

Jupiter is intended to be used as a framework for your custom application. However the example instance Jupiter IO which features an LRU cache and an InfoDB instance can also be directly used via docker: Docker image.

Further infos can be found on crates.io/crates/jupiter



Provides a helper which computes a average of a series of values.


Provides a builder which can be used to setup and initialize the framework.


Provides a compact and highly efficient representation of in-memory databases.






Contains the git commit hash of the Jupiter build being used.


Contains the version of the Jupiter library.



Initializes the logging system.