Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Do we need JMS in 21st century?

10,163 views

Published on

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. :)

Published in: Software

Do we need JMS in 21st century?

  1. 1. Do we need JMS in 21st century? Mikalai Alimenkou http://xpinjection.com @xpinjection
  2. 2. Disclaimer This is all my personal experience
  3. 3. Modern #NOJMS religion (Not Only JMS)
  4. 4. JMS is very old but still rocks
  5. 5. JMS 1.1 was over-abstraction
  6. 6. JMS 2.0 brings fresh breeze
  7. 7. 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
  8. 8. Complexity brings pain…
  9. 9. #1. There are no lost messages
  10. 10. 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
  11. 11. Message persistence is hard
  12. 12. “Features” make it even harder
  13. 13. Ultra performance by default
  14. 14. 100x slower in realistic cases
  15. 15. ActiveMQ looses messages
  16. 16. HornetQ looses messages
  17. 17. #2. Duplicates are impossible
  18. 18. Duplicates detection works well Special header with unique ID for each message Page out message once, redelivery policies Check if redelivered, constraints
  19. 19. 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.
  20. 20. 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?
  21. 21. 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?
  22. 22. Optimist-style development
  23. 23. OMG!?! HOW DID I USE IT BEFORE?
  24. 24. 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!
  25. 25. Welcome to the “dark side” of messaging! http://queues.io
  26. 26. #1. Local BlockingQueue Simple producer Simple consumer
  27. 27. Cook it with Apache Camel
  28. 28. Or with Spring Integration
  29. 29. #2. ZooKeeper + Curator
  30. 30. Different implementations
  31. 31. #3. Hazelcast
  32. 32. Embedded cluster message bus
  33. 33. Distributed queues in JDK style
  34. 34. #4. Redis
  35. 35. Lightweight Pub/Sub Simple producer Simple consumer
  36. 36. Reliable flexible queues on lists
  37. 37. BUT! You need enough RAM to store all messages.
  38. 38. #5. ZeroMQ
  39. 39. Implement simple server
  40. 40. Implement simple worker
  41. 41. #6. AMQP with RabbitMQ
  42. 42. Focused only on key features • Flexible reliability • Clustering • Federation • Highly available queues • Multi-protocol • Clients in different languages
  43. 43. #7. Amazon SQS
  44. 44. Reliable, scalable, cheap! Has JMS compatible driver…
  45. 45. Reliable, scalable, cheap! Has JMS compatible driver…
  46. 46. #8. Kafka
  47. 47. Sharded write-ahead log Always persistent with fault-tolerance. Messages are immediately written to the filesystem when they are received.
  48. 48. Data size doesn’t affect speed
  49. 49. Traditional author’s benchmark
  50. 50. 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
  51. 51. Think about what I told you today and may be the world will become a little bit better…
  52. 52. @xpinjection http://xpinjection.com mikalai.alimenkou@xpinjection.com

×