Taking Java heap dump programmatically

The following code snippet can be used to take heap dump of Java program programmatically.

import java.io.File;
import java.io.IOException;
import java.lang.management.ManagementFactory;

import javax.management.MBeanServer;

import com.sun.management.HotSpotDiagnosticMXBean;

public abstract class HeapDumper {

    private static final HotSpotDiagnosticMXBean HOT_SPOT_DIAGNOSTIC_MX_BEAN = getHotspotDiagnosticMxBean();
    private static final String HOTSPOT_BEAN_NAME = "com.sun.management:type=HotSpotDiagnostic";

    private static HotSpotDiagnosticMXBean getHotspotDiagnosticMxBean() {
        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        try {
            return ManagementFactory.newPlatformMXBeanProxy(
                    server, HOTSPOT_BEAN_NAME, HotSpotDiagnosticMXBean.class);
        } catch (IOException error) {
            throw new RuntimeException("failed getting Hotspot Diagnostic MX bean", error);

    public static void createHeapDump(File file, boolean live) {
        try {
            HOT_SPOT_DIAGNOSTIC_MX_BEAN.dumpHeap(file.getAbsolutePath(), live);
        } catch (IOException e) {
            throw new RuntimeException(e);

Issue #17: 10 Reads, A Handcrafted Weekly Newsletters for Humans

  1. Database Isolation Levels And Their Effects On Performance And Scalability: 10 mins read. It is always good to refresh the foundational concepts. This post covers database isolation levels:
    1. Read Uncommitted: This level allows one transaction to read uncommitted data written by another transaction. This isolation level allows dirty reads.
    2. Read Committed: This level allows one transaction to read data committed by another transaction. PostgreSQL uses READ COMMITTED as the default isolation level.
    3. Repeatable Read: This level ensures that during a transaction you are guaranteed to read the same data that were committed when the transaction was started even if you make multiple read calls. MySQL uses this level as default.
    4. Serializable: This isolation level ensures that all transactions occur in a completely isolated fashion, meaning as if all transactions in the system were executed serially, one after the other.
  2. How Sharding Works: 20 mins read. Database sharding is a complex topic to master. There are so many database and they all handle sharding differently. This post gives a good introduction to sharding and different ways sharding is implemented by different databases.
    1. Algorithmic sharding: This is implemented at the client side using an algorithm like hash(key) % number of servers in the database cluster
    2. Dynamic sharding: This is implemented using a locator service. Clients make call to locator service and it tells them which node to talk to.
    3. Entity groups: This approach stores related entities in the same partition to provide additional capabilities with in a single partition. This is a popular approach to shard a relational database.
    4. Hierarchical keys and Column-oriented databases
  3. Kubernetes for personal projects? No thanks! : 10 mins read. The article goes over reasons why you shouldn’t run Kubernetes cluster for a small project. I agree with the point. Your goal should be to build application rather than fighting with infra. I found Docker compose based deployment sufficient for my side projects. I provision a docker machine on AWS and then deploy containers using Docker compose. It works great when you are small. I think the same argument for Microservices and Monolithic applications. Don’t use Microservices architecture for small projects.
  4. Rate limiting for distributed systems with Redis and Lua: 15 mins read. This post explains how you can implement API rate limiting in your application. It shows how to do that using Redis and Lua scripts. It covers two use cases for API rate limiting 1) rate limiting upstream clients and rejecting calls above the limit 2) rate limiting downstream clients to ensure that they can maintain allowed calls per second.It uses Token Bucket and Leaky bucket algorithms to meet the use cases.
  5. A brief history of High Availability: 20 mins read. This article covers the history of how databases have evolved to support availability and consistency. It covers Active-Passive, Active-Active, and Multi-Active approaches to design available database clusters.

Two-phase commit protocol

Welcome to the fourth post in the distributed systems series. In the last post, we covered ACID transactions. ACID transactions guarantee

  1. Atomicity: Either all the operation succeed or none
  2. Consistency: System moves from one consistent state to another at the successful completion of a transaction
  3. Isolation: Concurrent transactions do not interfere with each other
  4. Durability: After successful completion of a transaction all changes made by the transaction persist even in the case of a system failure

If the database is running on a single machine then it is comparatively easier to guarantee ACID semantics in comparison to a distributed database. Following are the reasons you would want to run a database in a distributed fashion:

  1. To be fault-tolerant
  2. To handle more reads and writes

Let’s assume our’s is a read intensive application and our single machine database is not able to scale to our demand. One of the solution to scale read is achieved through replication. The most common replication topology is single master and multiple slaves. All the writes go to the master and reads are performed on slaves. Data from master is replicated to the salves synchronously or asynchronously. In this post, we will assume synchronous replication.

Read More »

Issue #16: 10 Reads, A Handcrafted Weekly Newsletters for Humans

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 165 minutes.  This week has stories on writing, remote code execution on Facebook servers, peter principle, Java 11 ZGC, Serverless patterns, PostgreSQL fast column creation, and few more.
Leadership is nature’s way of removing morons from the productive flow. – Dilbert

Read More »

Issue #15: 10 Reads, A Handcrafted Weekly Newsletters for Humans

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 190 minutes.  This week has stories on performance cost of containerization, how Slack built a scalable service for handling user preferences, productivity, security,  shallow reading, ACID transactions, and few more.
Whether you think you can, or you think you can’t – you’re right — Henry Ford

Read More »

The Minimalistic Guide to ACID Transactions

Welcome to the third post of distributed system series. So far in this series, we have looked at service discovery and CAP theorem. Before we move along in our distributed system learning journey, I thought it will be useful to refresh our memory with understanding of ACID transactions. ACID transactions are at the heart of relational databases. The knowledge of ACID transactions is useful when building distributed applications.

Understanding ACID transactions

A transaction is a sequence of operations that form a single logical unit of work. These transactions are executed on a shared database system to perform a higher-level function. An example of higher-level function is transferring money from one account to another. Transactions represent a basic unit of change in the database. It either executed in its entirety or not at all.

ACID (Atomicity, Consistency, Isolation, and Durability) refers to a set of properties that a database transaction should guarantee even in the event of errors, power failure, etc. The canonical example of ACID transaction is transfer of funds from one bank account to another. In a single fund transferring transaction, you have to check the account balance, debit one account, and credit another transaction. ACID properties guarantee that either money transfer from one account to other occur correctly and permanently or in case of failure both accounts have the same initial state. It would be unacceptable if one account was debited but the other account was credited.

Database transactions are motivated by two independent requirements:

  1. Concurrent database access: Multiple clients can access the system at the same time. This is achieved by the Isolation property of ACID transaction.
  2. Resiliency to system failures: System remains in consistent state in case of a system failure. This is provided by Atomicity, Consistency, and Durability properties of ACID transaction.

Read More »

Issue #14: 10 Reads, A Handcrafted Weekly Newsletters for Humans

Hello All,

Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 195 minutes. This week newsletter has stories on bullshit web, CAP theorem, slow thinking, productivity, faster JSON parsing with Stanford Sparser, Serverless, Shopify tech stack and few more.

It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint Exupéry

Read More »