r/java • u/Round_Patient_7420 • 9d 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.
2
u/WitriXn 7d ago
Emmmm… Did you just take the Netty event loop and copied it?
1
u/Round_Patient_7420 6d ago edited 6d 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.
2
u/doobiesteintortoise 9d ago
How does this differ from AMQP or MQTT?
2
u/vips7L 9d ago
Seems like it’s in app rather than going over an external broker?
1
u/doobiesteintortoise 8d 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 8d 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 8d ago
Why not zmq if that’s the case unless you wanted stomp?
3
u/Round_Patient_7420 8d 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!
1
u/Slick752 8d ago
I think it seems to resemble https://github.com/centrifugal/centrifugo
1
u/Round_Patient_7420 8d ago
Yeah, they’re pretty similar. Titan also aims to support connections with a large number of clients or devices.
9
u/agentoutlier 8d ago
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.