see http://openhft.github.io/Chronicle-Queue/apidocs/

Batching and Queue Latency

End-to-End latency plots for various message sizes

• Messages are grouped by topics.A topic can contain any number of sub-topics which are logically stored together under the queue/topic.

• An appender is the source of messages.

• A tailer is a receiver of messages.

• Chronicle Queue is broker-less by default.You can use Chronicle Datagrid to act as a broker for remote access.

At a high level:

• appenders write to the end of a queue.There is no way to insert, or delete excerpts.

• tailers read the next available message each time they are called.

By using Chronicle Datagrid, a Java or C# client can publish to a queue to act as a remote appender, and you subscribe to a queue to act as a remote tailer.

Chronicle Queue does not support operating off any network file system, be it NFS, AFS, SAN-based storage or anything else.The reason for this is those file systems do not provide all the required primitives for memory-mapped files Chronicle Queue uses.

If any networking is needed (e.g. to make the data accessible to multiple hosts), the only supported way is Chronicle Queue Replication (Enterprise feature).

Each topic is a directory of queues.There is a file for each roll cycle.If you have a topic called mytopic, the layout could look like this:

To copy all the data for a single day (or cycle), you can copy the file for that day on to your development machine for replay testing.

You can add a StoreFileListener to notify you when a file is added, or no longer used.This can be used to delete files after a period of time.However, by default, files are retained forever.Our largest users have over 100 TB of data stored in queues.

The only thing each tailer retains is an index which is composed from:

• a cycle number.For example, days since epoch, and

• a sequence number within that cycle.

  In the case of a DAILY cycle, the sequence number is 32 bit and the index = ((long) cycle << 32) | sequenceNumber providing up to 4 billion entries per day.if more messages per day are anticipated, the XLARGE_DAILY cycle, for example, provides up 4 trillion entries per day using a 48-bit sequence number.

  Printing the index in hexadecimal is common in our libraries, to make it easier to see these two components.

Appenders and tailers are cheap as they don’t even require a TCP connection; they are just a few Java objects.

Rather than partition the queue files across servers, we support each server, storing as much data as you have disk space.This is much more scalable than being limited to the amount of memory space that you have.You can buy a redundant pair of 6TB of enterprise disks very much more cheaply than 6TB of memory.

Topics are limited to being strings which can be used as directory names.Within a topic, you can have sub-topics which can be any data type that can be serialized.Messages can be any serializable data.

Chronicle Queue supports:

• Serializable objects, though this is to be avoided as it is not efficient

• Externalizable objects is preferred if you wish to use standard Java APIs.

• byte[] and String

• Marshallable; a self describing message which can be written as YAML, Binary YAML, or JSON.

• BytesMarshallable which is low-level binary, or text encoding.

An abstraction can be added to filter messages, or assign messages to just one message processor.However, in general you only need one main tailer for a topic, with possibly, some supporting tailers for monitoring etc.

As Chronicle Queue doesn’t partition its topics, you get total ordering of all messages within that topic.Across topics, there is no guarantee of ordering; if you want to replay deterministically from a system which consumes from multiple topics, we suggest replaying from that system’s output.

It is common practice to replay a state machine from its inputs.To do this, there are two assumptions that you have to make; these are difficult to implement;

• you have either just one input, or you can always determine the order the inputs were consumed,

• you have not changed the software (or all the software is stored in the queue).

You can see from this that if you want to be able to upgrade your system, then you’ll want to replay from the output.

Replaying from the output means that;

• you have a record of the order of the inputs that you processed

• you have a record of all the decisions your new system is committed to; even if the new code would have made different decisions.

Chronicle Queue provides the following guarantees;

• for each appender, messages are written in the order the appender wrote them.Messages by different appenders are interleaved,

• for each tailer, it will see every message for a topic in the same order as every other tailer,

• when replicated, every replica has a copy of every message.

Replication has three modes of operation;

• replicate as soon as possible; < 1 millisecond in as many as 99.9% of cases,

• a tailer will only see messages which have been replicated,

• an appender doesn’t return until a replica has acknowledged it has been received.

Most messaging systems are consumer-centric.Flow control is implemented to avoid the consumer ever getting overloaded; even momentarily.A common example is a server supporting multiple GUI users.Those users might be on different machines (OS and hardware), different qualities of network (latency and bandwidth), doing a variety of other things at different times.For this reason it makes sense for the client consumer to tell the producer when to back off, delaying any data until the consumer is ready to take more data.

Chronicle Queue is a producer-centric solution and does everything possible to never push back on the producer, or tell it to slow down.This makes it a powerful tool, providing a big buffer between your system, and an upstream producer over which you have little, or no, control.

Market data publishers don’t give you the option to push back on the producer for long; if at all.A few of our users consume data from CME OPRA. This produces peaks of 10 million events per minute, sent as UDP packets without any retry.If you miss, or drop a packet, then it is lost.You have to consume and record those packets as fast as they come to you, with very little buffering in the network adapter.

For market data in particular, real time means in a few microseconds; it doesn’t mean intra-day (during the day).

Chronicle Queue is fast and efficient, and has been used to increase the speed that data is passed between threads.In addition, it also keeps a record of every message passed allowing you to significantly reduce the amount of logging that you need to do.

Compliance Systems are required by more and more systems these days.Everyone has to have them, but no one wants to be slowed down by them.By using Chronicle Queue to buffer data between monitored systems and the compliance system, you don’t need to worry about the impact of compliance recording for your monitored systems.

Again, Chronicle Queue can support millions of events per-second, per-server, and access data which has been retained for years.

Chronicle Queue supports low latency IPC (Inter Process Communication) between JVMs on the same machine in the order of magnitude of 1 microsecond; as well as between machines with a typical latency of 10 microseconds for modest throughputs of a few hundred thousands.Chronicle Queue supports throughputs of millions of events per second, with stable microsecond latencies.

Articles on the use of Chronicle Queue in Microservices

Chronicle Queue can be monitored to obtain latency, throughput, and activity metrics, in real time (that is, within microseconds of the event triggering it).

As Chronicle Queue can be used to build state machines.All the information about the state of those components can be reproduced externally, without direct access to the components, or to their state.This significantly reduces the need for additional logging.

However, any logging you do need can be recorded in great detail.This makes enabling DEBUG logging in production practical.This is because the cost of logging is very low; less than 10 microseconds.Logs can be replicated centrally for log consolidation.

Chronicle Queue is being used to store 100+ TB of data, which can be replayed from any point in time.

Non-batching streaming components are highly performant, deterministic, and reproducible.You can reproduce bugs which only show up after a million events played in a particular order, with accelerated realistic timings.

This makes using Stream Processing attractive for systems which need a high degree of quality outcomes.

In Chronicle Queue we refer to the act of writing your data to the Chronicle queue, as storing an excerpt.This data could be made up from any data type, including text, numbers, or serialised blobs.Ultimately, all your data, regardless of what it is, is stored as a series of bytes.

Just before storing your excerpt, Chronicle Queue reserves a 4-byte header.Chronicle Queue writes the length of your data into this header.This way, when Chronicle Queue comes to read your excerpt, it knows how long each blob of data is.We refer to this 4-byte header, along with your excerpt, as a document.So strictly speaking Chronicle Queue can be used to read and write documents.

To write data to a Chronicle-Queue, you must first create an Appender

So, Chronicle Queue uses an Appender to write to the queue and a Tailer to read from the queue.Unlike other java queuing solutions, messages are not lost when they are read with a Tailer.This is covered in more detail in the section below on "Reading from a Queue".

Chronicle Queue uses the following low-level interface to write the data:

The close on the try-with-resources, is the point when the length of the data is written to the header.You can also use the DocumentContext to find out the index that your data has just been assigned (see below).You can later use this index to move-to/look up this excerpt.Each Chronicle Queue excerpt has a unique index.

The high-level methods below such as writeText() are convenience methods on calling appender.writingDocument(), but both approaches essentially do the same thing.The actual code of writeText(CharSequence text) looks like this:

So you have a choice of a number of high-level interfaces, down to a low-level API, to raw memory.

This is the highest-level API which hides the fact you are writing to messaging at all.The benefit is that you can swap calls to the interface with a real component, or an interface to a different protocol.

You can write a "self-describing message".Such messages can support schema changes.They are also easier to understand when debugging or diagnosing problems.

You can write "raw data" which is self-describing.The types will always be correct; position is the only indication as to the meaning of those values.

You can write "raw data" which is not self-describing.Your reader must know what this data means, and the types that were used.

Below, the lowest level way to write data is illustrated.You get an address to raw memory and you can write whatever you want.

You can print the contents of the queue.You can see the first two, and last two messages store the same data.

prints:

Chronicle Queue appenders are thread-local.In fact when you ask for:

the acquireAppender() uses a thread-local pool to give you an appender which will be reused to reduce object creation.

As such, the method call to:

will only give you the last index appended by this appender; not the last index appended by any appender.

If you wish to find the index of the last record written, then you have to call:

(note that tailer.toEnd() puts the tailer just past the last index written)

to count the number of messages between two indexes you can use:

for more information on this see :

Chronicle Queue stores its data in binary format, with a file extension of cq4:

This can often be a bit difficult to read, so it is better to dump the cq4 files as text.This can also help you fix your production issues, as it gives you the visibility as to what has been stored in the queue, and in what order.

The example below shows how to read a cq4 file from the command line:

You have to use the chronicle-queue.jar, from any version 4.5.3 or later, and set up the dependent files in the class path.To find out which version of jars to include please refer to the chronicle-bom.

Once you have the dependent jars on the class path (like below):

you can run, from the command line

this will dump the 19700101-02.cq4 file out as text, as shown below: