1 / 32

JMS – High level messaging

This document provides an introduction to the Java Messaging Service (JMS) and its implementation in CERN’s Accelerator Control System. It covers the architecture of JMS, including its broker model, message persistence, and communication protocols like STOMP and AMQP. It highlights the evolution and deployment of JMS at CERN, detailing its operational statistics, reliability, and the interconnectivity of different brokers. The content emphasizes the critical role of JMS in enabling reliable data transport for high-level control applications and efficient operations across various systems at CERN.

iona
Télécharger la présentation

JMS – High level messaging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Felix EhmCERN BE-CO JMS – High level messaging

  2. Content • Introduction • JMS in the Controls System • Deployment and Operation • Conclusion

  3. Introduction

  4. Introduction to JMS – The API • Java Messaging Service • Messaging API defined in 2002 • Decouples Source and Destination • Topic / Queue Concepts for named Destinations

  5. Introduction to JMS – A Broker • Technology originated from the financial sector • “Few” sources and large set of readers • A Broker is the central entity • Accepts messages from 1..* publisher and re-distributes to 0..*subscribers • Provides Quality of Service for Messages • Persistency, Transactions, Buffering, Expiration Policies, Slow Client Handling • Design to distribute data reliably and scalable • Load balancing / fail-over / embedded deployment scenarios possible Broker

  6. Introduction to JMS - A Broker • Many broker implementations available • ProprietaryIBM WebsphereMQ, SonicMQ, TIBCO, RedHat MRG, … • OpenSourceApache ActiveMQ, Apache Apollo, RabbitMQ, HornetMQ, … • Broker may be implemented in another language than Java (e.g. Qpid & RabbitMQ) • Communication protocol is non-standard • Brokers of different vendors are not interoperable • AMQP & STOMP address this issue

  7. Introduction to JMS - Request/Reply • “Direct communication” via Broker using Request – Reply mechanism • Due to intermediate Broker two hops are required Broker sends Requestor RequestMSG Replier Request Queue creates ReplyMSG sends Temporary Reply Queue

  8. Introduction to JMS - Selectors • Filter messages from one Destination usingMessages Selectors • Each message can be enriched with Attributes • Subscriber receives filtered messages via defined selector HEADERSCYCLE=ATIME=9845 JMS Message BODY Broker selector: BUILDING ≠ A BUILDING=A Topic/Queue Subscriber BUILDING=B BUILDING=C

  9. Introduction to JMS - Persistency • JMS defines persistent and non-persistentmessages • Broker stores message to disk before acknowledging to sender • Avoids loss of data when broker crashes • Drawbacks • Higher disk load • Slower message processing 1. send Sender 2. store 3. ack

  10. JMS in the Controls System

  11. CERN’s Accelerator Complex

  12. CERN’s Accelerator Complex

  13. JMS in the Controls System • Purpose • Reliable transport of data between (Java) Processes • High level controls applications + middle tier servers • Alarm System • Data Rendering Services • (Control) GUIs • Logging Services • Beam Security System(s) • Access Systems, …. • Today vital part of Beam Operations • Product choice: No JMS - No Beam !

  14. JMS in the Controls System - History • History • SonicMQ since 2001 for CERN’s Alarmand CO Monitoring system • OpenSourceActiveMQ since 2005 • Middle tier servers update GUIs • Middle tier to Middle tier Phased out in 2013

  15. JMS for Accelerator Controls • Early days only Java clients via JAPC • japc-ext-remote contains JMS communication • Today multi-language clients • JAPC clients remain • Java using ActiveMQ client libraries directly • C++/Python using STOMP

  16. Deployment and Operation

  17. Deployment and Operation • 29 production brokers • Single or broker cluster • Large spectrum of usage patterns • from few topics to 40K topics • from few subscribers to >23 K subscribers • from couple msg / minute to 10K msg / sec • from few bytes/msg to 3 Mbyte/msg

  18. Deployment and Operation Some numbers : • 300 Applications • 4’400 Connections • 40’000 Subscriptions • 85’000 Topics • 8 Million msg/h IN, 3.5M msg/h OUT Archived Uptime in 2012: 99.998% Not all data which is produced is also consumed

  19. Deployment and Operation • Distribute Load • Interconnect two Brokers • Consumers/Producer can choose any Broker • Sharing of work • Smooth Upgrades possible • Client library version != Broker version OK • Drawbacks • Consumer might not get all messages in case ofnetwork error • Routing overhead

  20. The STOMProtocol

  21. The STOMProtocol • Simple Text Oriented Message Protocol • Defines messaging API + wire format • Many open source clients libraries available • Python, C/C++, Java, Perl, Ruby, PHP, Erlang, … • Targets the messaging interoperability among language, platforms and brokers • Supported by many brokers • Very easy to use

  22. Example to send STOMP in Python mysocket = socket.socket(socket.AF_INET,socket.SOCK_STREAM) mysocket.connect( ("jms-co-dev", 61680) ) text = '''SEND\n\ destination:/queue/CERN.DEPLOYMENT\n\ HOST:%s\n\ INSTALLPATH:%s\n\ PRODUCT:%s\n\ TIME:%s\n\ persistent:false\n\n\x00''‘ mysocket.sendall(text) mysocket.sendall("DISCONNECT\x00") mysocket.close()

  23. The AMQProtocol

  24. The AMQProtocol • Advanced Message Queue Protocol • Defines messaging API + wire format • Next evolution after JMS • Consortium of RedHat, Credit Suisse, Microsoft, JPMorgen, Barclays, VMWare, Cisco, … • Released as Version 1.0 • More and more brokers implement it • Direction for the future ?

  25. Conclusion • JMS is vital part of Accelerator Controls System • Performs very well for publish - subscribe scenarios • ActiveMQwas agood choice • Running reliably • Low maintenance and flexible deployments • Provides many metrics for diagnostic and monitoring • Multi-language applications can use service • Central (redundant) service

  26. Result Example • Messages received/sec over time AVG Messages / sec time

  27. Result Example • Histogram of delayed message distribution # Messages Delay time [msec]

  28. Result Example • Number of “late” (>300ms) messages for test duration Delayed Messages time

  29. Message Delay Summary • Measuring delayed Message • ~ 99.32% of messages delivered < 300ms • Rest < 1 sec • Doubling numbers of messages (~9500 msg/sec) • 100% between 5 and 10 seconds • Further studies for improvement needed

  30. Result Example • CPU load Consumer disconnects Consumer connects % CPU load time 40% less CPU load thanks to optimization

  31. Broker Memory Consumption • Initial Memory is proportional to • Connections • Subscriptions 1000 Subscription / Connection 500 Subscriptions / Connection

More Related