JMS is known as standard way to implement distributed work with messaging in Java world. There are many JMS providers, both open source and commercial. Large percent of developers use JMS for almost every case when they want to sent message and process it on the other side. But now there are many alternative solutions to organize message queues: AMQP, Redis, ZooKeeper, Apache Kafka or even custom solutions based on Cassandra. Why not to use them instead of JMS? In this talk we will discuss key “issues” in any messaging system and then with this knowledge in mind look once again at JMS and alternative approaches using practical cases from my experience. May be after this talk some more people will stop using JMS and start using their mind. :)
12. Default config looses messages
• Non persistent messages
• No transactions on both sides
• No wait for ACK on producer side
• AUTO ACK on consumer side
• No flush on disc on every write
21. Duplicates detection works well
Special header
with unique ID
for each
message
Page out
message once,
redelivery
policies
Check if
redelivered,
constraints
22. But not always possible…
• The JMS transaction starts
• The destination object receives the message
• The DB transaction starts
• The DB stores the message
• Now since DB activity is over, DB transaction commits
• Now due to some reason, the JMS transaction fails and the
transaction is roll-backed.
23. But not always possible…
• The JMS transaction starts
• The destination object receives the message
• The DB transaction starts
• The DB stores the message
• Now since DB activity is over, DB transaction commits
• Now due to some reason, the JMS transaction fails and the
transaction is roll-backed.
May be use XA
transactions?
24. But not always possible…
• The JMS transaction starts
• The destination object receives the message
• The DB transaction starts
• The DB stores the message
• Now since DB activity is over, DB transaction commits
• Now due to some reason, the JMS transaction fails and the
transaction is roll-backed.
May be use XA
transactions?
29. Why do you send a message?
• Are consumers local?
• Do you run you app on a single node or distributed?
• Could you restore all messages from app state on restart?
• How many messages are you going to send?
• Are you restricted in technology choice?
• Is it critical if a message is lost?
JMS or not JMS?
This is a question!
47. Focused only on key features
• Flexible reliability
• Clustering
• Federation
• Highly available queues
• Multi-protocol
• Clients in different languages
55. Kafka at LinkedIn
300+ Kafka brokers
Over 18,000 topics
140,000+ Partitions
220 Billion messages per day
40 Terabytes In
160 Terabytes Out
Peak Load:
– 3.25 Million messages per
second
– 5.5 Gigabits/sec Inbound
– 18 Gigabits/sec Outbound
56. Think about what I
told you today and
may be the world
will become a little
bit better…