The document discusses the relevance of Java Message Service (JMS) in the 21st century, highlighting both its features and challenges, such as message loss and duplicate detection. It compares JMS to various alternative messaging solutions like Redis, AMQP, and Kafka, emphasizing the importance of considering application requirements and architectural choices. The author argues that while JMS has evolved, its complexity may not suit all modern messaging needs.

1. Do we need JMS in
21st century?
Mikalai Alimenkou
http://xpinjection.com
@xpinjection

3. Disclaimer
This is all my
personal experience

4. Modern #NOJMS religion
(Not Only JMS)

5. JMS is very old but still rocks

6. JMS 1.1 was over-abstraction

7. JMS 2.0 brings fresh breeze

8. Brokers have tons of features!
• Point-to-point messaging
• Publish/subscribe
• Request/reply messaging
• Message persistence
• Message prioritization
• Message routing
• Message types
• JMS transactions
• XA transactions
• Scalability
• Redelivery policies
• Async sends
• Delays and scheduling
• Destination policies
• Slow consumers
• Message selectors
• Exclusive consumer
• Virtual destinations
• Message groups
• REST API

9. Complexity brings pain…

11. #1. There are no lost messages

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

13. Message persistence is hard

14. “Features” make it even harder

15. Ultra performance by default

16. 100x slower in realistic cases

17. ActiveMQ looses messages

18. HornetQ looses messages

20. #2. Duplicates are impossible

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?

25. Optimist-style development

28. OMG!?! HOW DID I
USE IT BEFORE?

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!

30. Welcome to the
“dark side” of
messaging!
http://queues.io

31. #1. Local BlockingQueue
Simple producer
Simple consumer

32. Cook it with Apache Camel

33. Or with Spring Integration

34. #2. ZooKeeper + Curator

35. Different implementations

36. #3. Hazelcast

37. Embedded cluster message bus

38. Distributed queues in JDK style

39. #4. Redis

40. Lightweight Pub/Sub
Simple producer
Simple consumer

41. Reliable flexible queues on lists

42. BUT!
You need enough RAM to
store all messages.

43. #5. ZeroMQ

44. Implement simple server

45. Implement simple worker

46. #6. AMQP with RabbitMQ

47. Focused only on key features
• Flexible reliability
• Clustering
• Federation
• Highly available queues
• Multi-protocol
• Clients in different languages

48. #7. Amazon SQS

49. Reliable, scalable, cheap!
Has JMS compatible driver…

50. Reliable, scalable, cheap!
Has JMS compatible driver…

51. #8. Kafka

52. Sharded write-ahead log
Always persistent with fault-tolerance. Messages are
immediately written to the filesystem when they are
received.

53. Data size doesn’t affect speed

54. Traditional author’s benchmark

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…

57. @xpinjection
http://xpinjection.com
mikalai.alimenkou@xpinjection.com