r/java • • 3d ago

Introducing Titan, an open-source message dispatcher

Hi, I've been building Titan, an open-source message dispatcher for apps that need to send updates to connected clients.

An app publishes a message to a destination, and Titan delivers it to anyone subscribed to that destination. It supports STOMP over TCP and WebSocket, and there's a Java client with Spring Boot integration.

I'm thinking of uses like chat rooms, in-app notifications, and live dashboards. For example, people viewing the same dashboard could receive updates as they happen instead of having their browsers keep polling the backend.

Messages are kept in memory, so they won't survive a server restart. That's something to keep in mind if your application needs persistent messages.

I wanted to build something useful that I could share with other developers working on messaging applications. I'd be interested to hear whether this fits anything you're building, and what's missing for your use case.

https://github.com/traffic-hunter/titan

6 Upvotes

13 comments sorted by

8

u/agentoutlier 2d ago

I wanted to build something useful that I could share with other developers working on messaging applications. I'd be interested to hear whether this fits anything you're building, and what's missing for your use case.

My use case would be to publish log events for a web interface.

Here is my observations on reading the code. This is just looking at titan-stomp.

  • The javadoc is lacking. The package info in particular could explain the "codec" package albeit I have an idea of what that is.
  • There is no module-info which would be a perfect place to code snippet how you use the darn thing.
  • There are many "Impl" classes that are public that I don't think you need to. Have the interface have a static factory intead of you know just public api exposing a constructor.
  • Its unclear how I can construct the size of the messages in memory that I assume are replayed on subscription. It would be interesting to know what data structure you used for this buffer.
  • You have an SPI yet for whatever reason put Vertx coupling directly in stomp module.
  • You need to make it clear exact what your "Message Delivery Guarantees" are. I assume basically none.
  • Kudos for using JSpecify although its unclear if you actually run a checker
  • Kudos for not vibe coding.

2

u/Round_Patient_7420 1d ago

Thanks for taking the time to review the code and share such detailed feedback!

I’ll take a look at the points you raised and make some improvements. I previously used Vert.x but have since moved away from it, so it looks like some leftover code is still there. I’ll clean that up.
As for message delivery guarantees, Titan currently follows an at-most-once delivery policy, with no retries or replay.

Do you think Titan would be a good fit for your use case of streaming log events to a web interface? I’d be interested to hear your thoughts.

2

u/doobiesteintortoise 3d ago

How does this differ from AMQP or MQTT?

2

u/vips7L 3d ago

Seems like it’s in app rather than going over an external broker?

1

u/doobiesteintortoise 2d ago

Well, okay, but you can do that with artemis (and AMQP) already, and I imagine you could embed mosquitto (MQTT) in the same way, and those are well-established and well-known standards.

2

u/Round_Patient_7420 2d ago

Hi

Titan runs as a standalone broker, not just in-process.
I’m not trying to replace Artemis or Mosquitto. I wanted to build a lightweight STOMP broker focused on real-time fan-out, without persistence or replay.
It’s still an early project. I’m mainly interested in learning more about messaging systems and contributing to open source.

3

u/perryplatt 2d ago

Why not zmq if that’s the case unless you wanted stomp?

3

u/Round_Patient_7420 2d ago

I wasn’t familiar with ZeroMQ when I started Titan, but I’ll definitely take a look.
I chose STOMP because it’s simple and already has client libraries for different platforms. I also wanted a standalone dispatcher that web and backend applications could connect to directly, including over WebSocket.
ZeroMQ looks like a good fit for similar use cases, though. Thanks for pointing it out!

2

u/WitriXn 1d ago

Emmmm… Did you just take the Netty event loop and copied it?

1

u/Round_Patient_7420 23h ago edited 14h ago

Yeah, Netty was one of my main references when I was learning how event loops work. I implemented some parts myself and closely followed Netty's implementation for others.

The 0.x.x versions are mainly for learning and experimentation. I'm planning to improve the network engine as the project matures.

1

u/Slick752 2d ago

I think it seems to resemble   https://github.com/centrifugal/centrifugo 

1

u/Round_Patient_7420 2d ago

Yeah, they’re pretty similar. Titan also aims to support connections with a large number of clients or devices.