Chronicle


Feb 19, 2014 1 minutes read

Chronicle by Peter Lawrey:

This library is an ultra low latency, high throughput, persisted, messaging and event driven in memory database. The typical latency is as low as 80 nano-seconds and supports throughput of 5-20 million messages/record updates per second.

This library also supports distributed, durable, observable collections (Map, List, Set) The performance depends on the data structures used, but simple data structures can achieve throughput of 5 million elements or key/value pairs in batches (eg addAll or putAll) and 500K elements or key/values per second when added/updated/removed individually.

It uses almost no heap, trivial GC impact, can be much larger than your physical memory size (only limited by the size of your disk) and can be shared between processes with better than 1/10th latency of using Sockets over loopback. It can change the way you design your system because it allows you to have independent processes which can be running or not at the same time (as no messages are lost) This is useful for restarting services and testing your services from canned data. e.g. like sub-microsecond durable messaging. You can attach any number of readers, including tools to see the exact state of the data externally. e.g. I use; od -t cx1 {file} to see the current state.

See Also

JVM Profiling Mode

There is no sense to run profiler in instrumentation mode on a high load. Instead of using instrumentation you should use sampling mode. This article describes the difference between instrumentation and sampling modes. JVisualVM is a good free tool for this task.

Give Good Names for Your Threads

When configuring executors in multithreaded application, do not forget to assign names to your threads. It simplifies later profiling a lot, when you see a meaningful thread names in your profiler. For example, you may use CustomizableThreadFactory from SpringFramework for that.

Migrating Logback Configuration from XML to Groovy

I’ve recently switched logback configuration of our application from XML to Groovy. Configuration file is not about 5 times smaller and can be displayed on one screen! Groovy helped to remove duplicating parts of configurations by using for loop. The moving was easy thanks to online conversion tool. And don’t forget to add a groovy-all runtime dependency to your project config.

logo   Never miss a story, subscribe to our newsletter