Java on Prateek Sharma

Daemon threads for WebSocket keepalives

Sat, 29 Aug 2026 00:00:00 +0000

A WebSocket connection that needs periodic pings to stay open shouldn’t run that ping loop on a plain, non-daemon thread. In the WazirX Java connector , the ping thread is started onOpen and marked setDaemon(true) before starting it:

pingThread = new Thread(new PingMessage(this));
pingThread.setDaemon(true);
pingThread.start();

A non-daemon thread keeps the JVM alive until it finishes. If a caller opens a socket, forgets to close it, and the rest of the application shuts down, a non-daemon ping thread will keep the process running indefinitely. A daemon thread just gets killed when everything else is done — which is the right default for background keepalive work that isn’t itself the point of the program.

Give callers two error types, one extending the other

Fri, 28 Aug 2026 00:00:00 +0000

In the WazirX Java connector I split errors into two:

WazirxClientException — the caller made a mistake the caller can fix: a bad side value, a missing required field. Thrown before a request is even sent.
WazirxApiException — something went wrong once the request left the process: a network failure, a non-2xx response.

WazirxClientException extends WazirxApiException. That one line is the whole design. A caller who only cares “did this work?” catches the parent. A caller who wants to retry network failures but fail fast on their own bad input catches both separately. Nobody is forced into a giant catch (Exception e) that swallows bugs, and nobody has to try/catch five specific types at every call site.

WazirX Java Connector

Sun, 23 Aug 2026 00:00:00 +0000

After building the Go connector for WazirX, I wanted the same thing on the JVM — but WazirX doesn’t publish an official Java client at all, REST or WebSocket. The REST half was a fairly direct port of what I’d already learned building the Go client. The WebSocket half turned out to be its own project.

Letting callers choose their failure granularity

For errors, I didn’t want every caller forced into one giant catch-all exception, but I also didn’t want to force a try/catch at every single call site. I split errors into two, with one extending the other:

Adda52 — Delta Corp

Mon, 01 Sep 2014 00:00:00 +0000

Adda52 is one of India’s largest real-money poker platforms. I joined as a graduate trainee in 2014 and left in 2020 as a Senior Software Engineer, working across the game backend, load and resilience testing, and the public platform.

Role progression

Graduate Engineer Trainee (Sep 2014 – Oct 2015)
Software Engineer (Oct 2015 – Oct 2016)
Senior Software Engineer (Oct 2016 – Feb 2020)

Engineering areas

Game logic

Contributed to core poker cash-game and tournament-management modules.
Implemented the OFC poker variant end to end on the adda52live.com frontend (Angular 2).

Load and resilience testing

Enhanced Java-based user-behaviour simulators to load test real-time poker servers at 10,000+ concurrent users.
Built disaster-recovery systems for zero-downtime gameplay — restoring poker games and player state after a failure.

Platform migration

Led migration of the public gaming platform from PHP to Node.js, improving performance and maintainability.
Built Angular 2 interfaces for event bookings on adda52live.com and user-segmentation logic for targeted marketing.

Delivery

Developed Gradle-based CI/CD pipelines with Jenkins, automating builds and reducing integration friction.
Represented a 6-member team in sprint planning and stakeholder meetings, coordinating with QA, product, and DevOps.

Stack

Java · Node.js · Angular 2 · Jenkins · Gradle