PPT, PDF9,268 views

ActiveMQ 5.9.x new features

This document provides an overview and agenda for a presentation on Apache ActiveMQ 5.9.x and Apache Apollo. The presentation will cover new features in ActiveMQ 5.9.x including AMQP 1.0 support, REST management, a new default file-based store using LevelDB, and high availability replication of the store. It will also introduce Apache Apollo and allow for a question and discussion period.

Technology◦

ActiveMQ 5.9.x new features

1.
11 Apache ActiveMQ 5.9.x and ApacheApollo Christian Posta Senior Consultant and Architect 09/11/13
2.
2 • Apache ActiveMQ •New features! • Demos • Apache ActiveMQ Apollo Agenda for the night
3.
3 Your speaker Christian Posta Blog:http://christianposta.com/blog Email: ceposta@apache.org Twitter: @christianposta • Senior Consultant and Architect at Red Hat (formerly FuseSource) • Committer at Apache Software Foundation: ActiveMQ, Apollo • PMC at ActiveMQ • Author: Essential Camel Components DZone Refcard • Contributor to Apache Camel
4.
44 Apache ActiveMQ
5.
5 • The mostwidely used open-source messaging broker • Highly configurable • Friendly license (no license fees!) • Vibrant community (TLP) • Backbone of top enterprises in retail, e-retail, financial services, shipping, many others! Apache ActiveMQ
6.
6 • High performance •High availability • Light-weight • Multi-protocol • JMS compliant • Backed by Red Hat! ActiveMQ Features
7.
7 • TCP, NIO •UDP • SSL, SSL+NIO • VM • HTTP • WebSockets Breadth of connectivity
8.
8 • OpenWire • STOMP1.0, 1.1, 1.2 • MQTT 3.1 • AMQP 1.0 Breadth of connectivity
9.
9 • Asynchronous architectures •Reliable message passing • Loose coupling • Heterogeneous integration • Real-time data When to use ActiveMQ
10.
10 10 ActiveMQ 5.9.0
11.
11 • AMQP 1.0protocol • REST management with Jolokia • Pure master slave deprecated and removed • Java 7 support • Split up client libs, modularize core packages Quick recap of 5.8.0 release
12.
12 • Fall 2013 •New, faster, default file-based store • Persistence store HA replication • New management console, HawtIO • New “broker:” Camel component • Other new features ActiveMQ 5.9 on its way!
13.
13 13 Default file-based store
14.
14 • LevelDB • Hardened •JNI (native) and Java versions • Java version packaged by default https://github.com/dain/leveldb • Can download http://code.google.com/p/leveldb/downloads/list Default in 5.9.0 – LevelDB
15.
15 • AMQ MessageStore (deprecated!!!) Don’t use this one! • KahaDB • LevelDB File-based stores
16.
16 • Journal /TX Log • Indexes • Recovery Logs File-based stores Index Journal Redo Log X X X X
17.
17 • Homegrown • Optimizedfor messaging • TX log, WAL log, Indexes • B-Tree based indexes • Known bottlenecks KahaDB
18.
18 • Google NoSQLkey-value DB http://code.google.com/p/leveldb/ • Based on BigTable • Chrome, Riak, IndexedDB • No relational model, queries, indexes • Store keys sorted LevelDB
19.
19 • Underlying datastructures are optimized for sequential access and lots of writes http://en.wikipedia.org/wiki/Log-structured_merge-tree • Concurrent reads • Pause-less log cleanup • Built-in compression • JMX LevelDB cont’d
20.
20 LevelDB vs KahaDB
21.
21 • Makes forvery fast store index! • Fewer entries in index • Composite sends only store message once • HDFS support! • Replication!?... LevelDB Store
22.
22 22 LevelDB Replication
23.
23 • What isHA!? • JDBC master-slave • Shared file-system master-slave • Pure master-slave (deprecated! don’t use!) Recap – ActiveMQ HA
24.
24 • LevelDB non-shareddistributed replication! • What is it? New in 5.9.0 – ActiveMQ HA
25.
25 • Failover • failover(tcp://host1:61616,tcp://host2:61616) •Supported in Openwire clients • Java, C#, C++ • Static vs Dynamic discovery Client side HA ActiveMQ Cluster ActiveMQ Client
26.
26 ActiveMQ – HighAvailability Broker Slave Client Larry’sRemovals Broker Slave
27.
27 JDBC Master-Slave Broker Slave Broker Master Client Broker Slave Database
28.
28 • Extreme reliability– but not as fast • Recommended if already using an enterprise database • No restriction on number of slaves • Simple configuration JDBC Master-Slave
29.
29 Broker Slave Broker Master Client Broker Slave File System Larry’sRemovals Shared FileSystem M/S
30.
30 • Recommended ifyou have a SAN, or DRBD • Ensure file locking works – and times out – NFSv4 good! https://issues.apache.org/jira/browse/AMQ-4378 • No restriction on number of slaves • Simple configuration • Best performance Shared File System M/S
31.
31 Local File SystemLocal File SystemLocal File System Broker Slave Broker Master Broker Slave ZooKeeper Cluster Replicated LevelDB Master Slave – NEW!
32.
32 ZooKeeper Cluster Local File SystemLocal File SystemLocal File System Broker Slave Broker Master Client Broker Slave Larry’sRemovals Replicated LevelDB Master Slave
33.
33 • Requires aHA ZooKeeper Cluster • No Single Point of Failure • Dynamic number of slaves • Sync Replication • Local Mem/Disk • Remote Mem/Disk • Quorum Mem/Disk Replicated LevelDB Master Slave
34.
34 <broker brokerName="broker" ...> <persistenceAdapter> <replicatedLevelDB directory="activemq-data" replicas="3" bind="tcp://0.0.0.0:0" zkAddress="zoo1.org:2181,zoo2.org:2181,zoo3.org:2181" zkPassword="password" zkPath="/activemq/leveldb-stores” /> </persistenceAdapter> </broker> Replicated LevelDB Config
35.
3535 Demo
36.
36 36 New Management Console
37.
37 Old Web Console
38.
38 • Manage integrationinfrastructure from one dashboard • Customizable • Plugins • Camel • ActiveMQ • Fabric • Infinispan • Tomcat • Many others! • Visualizations • One dashboard to rule them all HawtIO – http://hawt.io
39.
39 • Default ActiveMQdashboard • Visualization of health • Access to operations to make changes • Move messages from DLQ to original destinations • Visualize Camel routes deployed along with broker • Send messages • Real-time metrics HawtIO – http://hawt.io
40.
40
41.
41 Demo time… Camelhelp <route> <from uri="timer://foo? fixedRate=true&period=5000"/> <transform> <simple>The time is: ${date:now:HH:mm:ss}</simple> </transform> <to uri="activemq:example.A" /> <to uri="activemq:time.me.out?timeToLive=5000"/> </route>
42.
42 Demo time… Camelhelp <route> <description>Example Camel Route</description> <from uri="activemq:example.A"/> <to uri="activemq:example.B"/> </route>
43.
4343 Demo
44.
44 44 New Apache Camel BrokerComponent
45.
45 • Virtual Topics •Composite Destinations <compositeQueue name="MY.QUEUE"> <forwardTo> <queue physicalName="FOO" /> <topic physicalName="BAR" /> </forwardTo> </compositeQueue> • Broker Plugin Destination Interceptors
46.
46 • Use ApacheCamel routes • Creates destination interceptor at runtime • Embed in camel.xml and deploy with ActiveMQ • More powerful than existing interceptors (use when needed) • http://rajdavies.blogspot.com/2013/09/apache-camel-broker-component-for.html? tw Broker component
47.
47 <route id="setPriority"> <from uri="broker:topic:test.broker”/> <setHeaderheaderName="JMSPriority"> <constant>9</constant> </setHeader> <to uri="broker:queue:test.broker.component.queue"/> </route> Broker component
48.
48 48 Other Changes
49.
49 • MQTT overWebSocket – https://issues.apache.org/jira/browse/AMQ-4617 • Slow consumer policy – https://issues.apache.org/jira/browse/AMQ-4621 • AMQP hardening – multiple jiras • Restart on lost lock – https://issues.apache.org/jira/browse/AMQ-4526 Other notes for 5.9.0 release
50.
50 • Checkout theActiveMQ wiki: http://activemq.apache.org • Mailing list: users@activemq.apache.org • My Blog: http://christianposta.com/blog • Books: ActiveMQ in Action – Dejan Bosanac, Rob Davies Instant ActiveMQ Messaging Application Development – Tim Bish Wrap up ActiveMQ 5.9.0
51.
5151 Apache ActiveMQ Apollo
52.
5252 QuestionsQuestions andand DiscussionDiscussion

Editor's Notes

#4 Say some things about FuseSource + Red Hat here… and what I do… So I started out working for FuseSource about a year and a half ago. Fuse Source was a open-source subscription company built around the integration projects at Apache, specifically Apache ActiveMQ, Camel, ServiceMix, and CXF. Basically these projects are best-of-breed and highly adopted freely by community users and used for mission critical infrastructures when building out SOA and other distributed integrations. The thing is, big companies who invest millions of dollars into their businesses aren’t willing to accept using a mailing list and irc for production support, aka when shit hits the fan, they need to be able to rely on some strong partners who would be able to help them out. That’s were fuse source, fit into that picture. It was started by the guys that co-founded the projects, and they were able to build up an amazing set of support engineers and consultancy teams. Along the way, they hired up a lot of the committers on each of the respective projects, and put together professional documentation, on-site and virtual training, an annual conference devoted specifically to these technologies, as well as and most importantly support subscriptions for both production and dev support. We were officially welcomed into the Jboss Redhat family almost exactly a year ago and the spirit of open-source itnegration and SOA lives on under the RedHat umbrella and in complement of the existing Jboss offerings including EAP, Drools/BRMS, and jBPM, etc.
#6 What is activemq… how would I explain what that is?? A message broker… it moves messages from a producer to a consumer.. It takes the responsibility of delivering a self-contained piece of data between two clients… the producing client doesn’t have to know key details usually found in traditional RPC.. Where is the client? Is the client ready to handle a message? What communication protocol can the client support? A messaging broker helps to abstract away all of those details in an effort to make the programming model conceptually easy… a producer is responsible for producing data.. But how it gets to where it needs to go is delegated to another entity. This is beneficial because it keeps the producer simpler, keeps the interaction simple (from A to B), decouples producer and consumer, and many other things. High level: alleviates responsibility from producer to deliver messages. Low Level: takes a piece of data and tries to deliver it as fast and reliably as possible Highly configurable – swiss army knife of messaging, because messaging use cases vary so widely. What type of messaging, how many consumers/producers, what to do in failure scenarios, what level of througput or latency do you need, what type of hardware and OS are you running on, clustering, HA, reliable/unreliable network, etc… there is no one solution that fits all… Vibrant community – very active mailing list (usually within 15 mins response), JIRAs, bug fixes, new features, books, Zappos, UPS, Home Depot, Walmart, Harris Corp, Yahoo, FAA, SAA, Ticketmaster, GM, IHG, Sabre, CERN, Mars rover projects, Wells Fargo,
#7 Some of the main features from ActiveMQ, and reasons why so many people use it, include High performance… so moving messages asynchronously from a producer to eligible consumers as quickly and as efficiently as possible. High availability… so getting messages from A to B is easy when everything is working correctly, but as you all probably already know, distributed systems have to be able to cope with failures, because failures and unplanned disruptions are basically the “norm”.. The larger the network of your distributed system, the higher chance something will go wrong Light-weight… of course these all sound like buzzwords because they’re so overused and abused by those people interested in selling you stuf… but activemq is truly light-weight in that it can be deployed stand alone, in any J2EE container if desired, or even embedded within your own java application. Other messaging brokers, like MQ Series or even other open-source alternatives like Rabbit, cannot be embeded into your Java app … but why would you do that? Well, just like you can build highly performant, scalable distributed systems, so too can you architect your app internally to use asynchronous message passing, but with reliability built in, and options for extensibilty when needed by using broker networks, and routing with camel, etc.
#8 Some of the main features from ActiveMQ, and reasons why so many people use it, include High performance… so moving messages asynchronously from a producer to eligible consumers as quickly and as efficiently as possible. High availability… so getting messages from A to B is easy when everything is working correctly, but as you all probably already know, distributed systems have to be able to cope with failures, because failures and unplanned disruptions are basically the “norm”.. The larger the network of your distributed system, the higher chance something will go wrong Light-weight… of course these all sound like buzzwords because they’re so overused and abused by those people interested in selling you stuf… but activemq is truly light-weight in that it can be deployed stand alone, in any J2EE container if desired, or even embedded within your own java application. Other messaging brokers, like MQ Series or even other open-source alternatives like Rabbit, cannot be embeded into your Java app … but why would you do that? Well, just like you can build highly performant, scalable distributed systems, so too can you architect your app internally to use asynchronous message passing, but with reliability built in, and options for extensibilty when needed by using broker networks, and routing with camel, etc.
#9 AMQP (1.0) A binary format originally from JPMorgan Chase, Originally targeted toward wire-level and messaging semantic interoperability between messaging vendors, but with version 1.0, it has removed some of the semantics of exchanges and queing and is essentially a wire-level protocol. ActiveMQ uses the popular Proton project, which is the same underpinnings of Apache Qpid. MQTT (3.1) A super-compact bianry protocol developed by IBM and others intended to be used exclusively for reliable pub-sub for limited devices on highly unreliable networks. think small monitoring devices like gas meters, pacemakers, medical sensors, car sensors, etc. The idea is to allow all of these sensors out in the field collecting data, known as the "internet of things" to be able to reliably transmit their data through messaging. OpenWire (v1-10) Is the original binary wire-level protocol intended to be an open standard. It's used to implement the JMS API in a highly-performant and feature-rich way. Used by default unless you explicitly specify another proptocol. Backward compatible (as discussed above) with previous versions. STOMP (1.0, 1.1, 1.2) Simple Text Oriented Messaging Protocol who's main goals are simplicity and basic connectivity: get a client talking to the messaging broker regardless of what platform, or programming language that's used. As a result, clients exist in python, ruby, scala, perl, c/c++, .Net, Delphi, JavaScript, Objective-C, PHP, Erlang, Go, etc, etc.. point is, it's a text-protocol that's easy to implement so many languages already have and are using it.
#10 Async integration – allowing apps to do what they are focused on doing without being tied to the dependencies of other systems just because they need to integrate. For example, App A shouldn’t have to tie up threads and resources trying to communicate with App B synchronously or when App B is not available. The idea is to let App A send its message (data) off knowing it will get to App B when App B is ready to handle it, but not take responsibility for that data xfer. That way App A can continue to do the processing it needs on its side, and if it needs to be aware of a response from App B, that response will show up asynchronously and handled when App A is ready to. Using asynchronous processing like this is one important way to get higher throughput and utilization of your systems. When App A needs to send a piece of data to B, not only does it want to do so fast and efficienlty, but it wants to have some level of guarantee that the data didn’t get lost. ActiveMQ plays the part of mediator and broker here by establishing protocols with the producers and consumers to guarantee message delivery even in the face of unplanned failures. Loose coupling – coupling really should be thought of In terms of levels or degress of coupling. Or better yet, the assumptions made by one system on the other system. Asumptions like availability, programming language, data types, network interruptions, etc, are dealt with and aleviated in some cases with messaging. Heterogeneous architectures – be able to reduce the spider web of point to point connections and allow apps written in different languages on different platforms, owned by different groups with different upgrade paths and different lifecycles to be able to reliably communicate with each other. http://www.openamq.org/doc:amqp-background
#12 AMQP 1.0 protocol was first introduced. AMQP was introduced in 2004-2005 JP Morgan Chase as a way to “commoditize” messaging platforms and achieve interoperability between clients and servers. The original spec and still the 0.8 and 0.9 specs forced certain implementation details onto the different brokers and that severely limited adoption. For 1.0 release, a lot of the implemention detail was removed and it’s now just a binary wire-level protocol. It still remains to see what level of “interoperability” can be achieved. But we do support it. ActiveMQ’s impl is powered by the Apache Qpid proton project which is a protocol engine that third parties can use to easily build out AMQP clients and servers. Jolokia is an awesome opensource project that basically provides an alternative to JSR-160 which specifies the connectors that one typically uses for JMX connections. Usually, it’s done by setting up an mbean server which registeres some JNDI and RMI endpoints which you connect to. Jolokia on the other hand is implemented as a java agent which allows HTTP/REST JSON access to the JMX mbeans. It also provides features like bulk requests, fine-grained security and authorizations, etc. Pure master slave deprecated – and now removed and not available… this was the original “shared nothing” master slave, where the master would dispatch to the slave before ack’ing the producer. In this scenario, if a master went down, the slave would be live and be able to take over. Some of the drawbacks of this approach is there would need to be manual intervention to restore the original master as a slave. So you would have to stop the slave, re-sync the master/slave manually, then restart the pair again. Started testing and certifying for Java7 Refactored a lot of the packages so that are more cleanly organized and can be included as dependencies more finely… for example, if you wanted to strip down the distro to its most bare and required components. Or if you wanted to split out the client libs so that you don’ t need to icnlude the broker code too
#13 Expected out this fall.. The last few bug fixes are being committed as we speak, most large features are already baked and ready for release, but since this is still an open-source and community driven project, we do it in our spare time and are working as best we can to get it out  We can expect the default store, to change from KahaDB which has served us very well the past couple years, to a newer faster store. We have some new options for HA replication. New management console which has been long over due. Other features like MQTT over websockets, and others I will briefly mention And of course, the community as well as our commercial customers have unearthed some obscure use cases that bring to life some bugs which we quickly squash.
#15 So LevelDB will become the new default store in the 5.9.0 release. Curious if any in this room have played with LevelDB with or without ActiveMQ? We’ve already had a lot of adoption of it in the community and in commercial customers, and we’ve received a lot of feedback. It’s been hardened and now be ready for prime time. There are two different implementations: a native version and a pure java version. The Java version was ported from the native C++ implementation by Dain Sundstrum (a brilliant dude who works at Facbook now). The java version is what’s shipped and enabled by default in the community distro of 5.. There is also the native version available directly from and maintained by google at the link above. This is written in C++ and takes advantage of some of the specific OS features such as AIO and can be faster in some use cases.
#16 There are effectively two file-based stores currently in ActiveMQ. KahaDB and LevelDB. There is also the original AMQ store which still lingers in previous versions. This version is not supported anymore and should not be used. It’s slower, a little more complex that it needs to be, and is not even available in the newer releases. The other two provide much better performance.
#17 So KahaDB is an awesome file-based messaging DB… it has served the community very well for the past years, including helping us beat out IBM MQ series at UPS  It’s very fast, good recovery time on failover, well understood, highly tunable. It was homegrown written by the original project co-founders to better fit the messaging paradigm by keeping as much of the index in memory as possible, batching writes to the disk, and allowing to tune page size, buffers, checkpoints, recovery mechanisms, and others. Its implemented using some of the traditional db components like B-tree indexes, write-ahead-logs, and transaction logs, however, it’s highly optimized for writes and deletes, whereas a traditional RDMS is highly optimized for reads and complex queries. There are known limitations in the implementations and bottlenecks when approaching its limits and they usually show up in the indexes. There are multiple btree indexes to help preserve message order, message priority, durable subscriptions and others. Having to update all these data structures, no matter how creatively, using btress becomes expensive at the upper limits of performance. So, actually, when proving out theories in Apache Apollo, which I’ll talk about next, we found LevelDB to fit our usecases very well.
#18 So KahaDB is an awesome file-based messaging DB… it has served the community very well for the past years, including helping us beat out IBM MQ series at UPS  It’s very fast, good recovery time on failover, well understood, highly tunable. It was homegrown written by the original project co-founders to better fit the messaging paradigm by keeping as much of the index in memory as possible, batching writes to the disk, and allowing to tune page size, buffers, checkpoints, recovery mechanisms, and others. Its implemented using some of the traditional db components like B-tree indexes, write-ahead-logs, and transaction logs, however, it’s highly optimized for writes and deletes, whereas a traditional RDMS is highly optimized for reads and complex queries. There are known limitations in the implementations and bottlenecks when approaching its limits and they usually show up in the indexes. There are multiple btree indexes to help preserve message order, message priority, durable subscriptions and others. Having to update all these data structures, no matter how creatively, using btress becomes expensive at the upper limits of performance. So, actually, when proving out theories in Apache Apollo, which I’ll talk about next, we found LevelDB to fit our usecases very well.
#19 LevelDB, as mentioned, is a nosql key-value database from google inspired by their work on map reduce, bigtable, and big data storage algorithms. It’s currently used in Chrome, Riak,
#20 So the LevelDB based store still uses WAL and TX logs, but we now use the LevelDB engine to index the tx log. So now we rely on log-structured merge trees, not btrees, and google’s algoriitm for sorting and compressing things. The structures since they are sorted are very friendly for sequential access type systems, like messaging. They also allow very good concurrency features including reads, wheras kahadb had lots of locks and contention on reads and writes. We also use fewer entries per message and destination, which itself also reduces contention at the index… It also comes with throw-in features like JMX out of the box
#21 So what does this mean? "enqueue" "drained enqueue" and "loaded enqueue"? enqueues while there are no consumers (queue starts empty) enqueues while the queue is being drained (it has consumers) enqueues when queue is very large (millions of messages) in benchmarks against kahadb, we see that it outperforms quite a bit. This is using 20 byte structures and async sends: Questions: What are “loaded enqueues” vs loaded dequeues, vs drained enqueues, etc. We use 20 byte bodies here to really push the storage engine. We don’t use larger bodies because then the data is natrually batched, and would give better performance. So we choose usecases and payloads that would inherently require the store to figure out how to properly batch and deal with the payload.
#22 There is also support for HDFS! So basically the store will keep a local copy as well as upload to HDFS and sync anything missed at regular checkpoints. When a master fails, and a slave takes over, it will d/l the last known sst files with latest indexes. Then normal recovery kicks in. Note, for this set up, Master/Slave elections are started manually or coordinated externally with something like zookeeper. Pauseless log clean up – kahadb had period cleanup intervals during which log operations were suspended.. This isn’t the case with the leveldb indexes and cleanup Composite sends, like Virtual Topics, or the new JMS 2.0 durable subscribers, or fanout-type sends to multiple destinations
#24 What is HA? High Availability… but people have different notions of what HA is… You can have two basic types with ActiveMQ: #1 where messages get high-availability in this case, you have producers and consumers to a broker that require their messages to be delivered even in the case of faults. So if a producer sends to broker A, then broker A guarantees deliver to consumers. #2 where clients must be able to connect and send to a broker.. Regardless of past messages, and with the most minimal of delay… We will be talking about the first kind, where clients must be able to eventually connect to a broker and messages guaranteed to be delivered…
#25 Note these are the out of the box configs for HA,… but consider network of brokers to play a role in HA also…
#26 The high-availability features in activemq depend on the client participating and able to failvoer to the slave brokers when connectivity to the master has been interrupted. To do that, you can use the failover transport which takes URIs for the brokers participating in the HA cluster. The failover is supported out of the box for the Java, .NET and C++ clients. In this case if the master goes away, the client will attempt to connect to the slave. There are parameters for prioritizing the backup (so that the client goes back to the master if the msater becomes available) or for delayed or exponential back off, or randomizign the attempts to reconnect, etc. You can also rely on different discovery mechanisms for locating the brokers in the cluster. You can use Fuse Fabric which under the covers uses zookeeper to locate master/slaves
#27 The general pattern is for Slaves to be in warm-standby mode so that if a master gets hit by a truck, a slave will be elecftd master and the client will rely on its failover protocol to be able to detect which broker is the slave and connect to that one Transactions that have not been committed and are in progress are replayed upon reconnection. These HA scenarios shown above currently rely on some kind of shared backing store like NFS or SAN or RDBMS.
#28 Note these are the out of the box configs for HA,… but consider network of brokers to play a role in HA also…
#29 Simple to configure, easy to understand, uses DB table locks, or lease locks. So the master will first grab the exclusive lock, and all slaves will sit idle until the msater has relinquished the lock. So you can have as many idle broker slaves listening for the lock. The first to get the lock when master goes down becomes elected master. We’ve seen this in enterprises where there is good in-house expertise in RDBMs and they are comfortable administering the DB as SPOF and creating redundant solutions for the DB. Also, one thing to keep in mind, RDBMs are not optimized for messaging based use-cases, and will not be nearly as performant as the file-based solutions. On the other hand, all of your RDBMs tools are relevant, messages can be queried, etc…
#31 Ensure your shared file locks work This requires distributed exclusive locks, thus file systems that support this. Because the election depends on the master getting the lock while slaves line up behind waiting for the lock. Basically boils down to being able to take take locks using the way the JVM creates locks (using posix locks, lockf and fcntl). flock is not sufficient… for eg, ocfs2 uses flock but w. newer linux kernel can be run in “ userspace cluster ” that uses lockf and AMQ can use that. You can add as many slaves as you’d like. Highly tunable for best performance.
#32 Coordination and master election are handled by Zookeeper Apache Zookeeper is a distributed coordination and configuraiton service that itself is HA. It is a TLP from Apache that originated as the cluster coordination service used by Hadoop in a Hadoop cluster. You can use zookeeper to build out distributed data structures (queues), locks, synchronizations,, or use it for central location for configuration, or master election. Zookeeper behaves properly when nodes go down, and even during network partiitions. Zookeeper ensemble should always be odd, 1, 3, 5, etc. because a majority is always needed for voting This is what Fuse Fabric uses. Think of it kinda like an LDAP with directory structure with znodes Locks, Barriers, Queues, Master Election, Rendezvous, Group Membership
#38 Management of your middleware infrastructure is critical. ActiveMQ had two main avenues for management and monitoring: #1 JMX through Jconsole, VisualVM, or using a tool like nagios or any of the commercial options for monitoring. #2 was a web-based console that shipped out of the box. The webconsole does give basic overview so you can see queues, basic destination stats, connections, network connectors, etc. Bottom line it was fairly limited, had no visualizations, and could not perform some very common and needed operations on the broker. For example, it was clumsy to move a message from a DLQ back to an original destination. However, one of the biggest motivations for moving away from this webconsole is: Every product comes with its own console! ActiveMQ’s was “just another console” .. So when you had FuseESB which contained ActiveMQ, Karaf, Felix, Camel, and potentially other JVM based apps with their own consoles, you had n consoles which becomes a huge pain.
#39 So HawtIO is a single page web app written with angular-js and written with plugins and customization in mind. It’s intended to be the one and only one console that your JVM apps need for monitring and visualiztions. HawtIO will automatically discover your plugins or services that it knows how to manage and will enable them on your dashboard. It can mange and visualize your Camel, ActiveMQ, Fabric, FuseESB, Jboss, Infinispan, tomcat, others….
#40 So HawtIO is a single page web app written with angular-js and written with plugins and customization in mind. It’s intended to be the one and only one console that your JVM apps need for monitring and visualiztions. HawtIO will automatically discover your plugins or services that it knows how to manage and will enable them on your dashboard. It can mange and visualize your Camel, ActiveMQ, Fabric, FuseESB, Jboss, Infinispan, tomcat, others….
#42 Management of your middleware infrastructure is critical. ActiveMQ had two main avenues for management and monitoring: #1 JMX through Jconsole, VisualVM, or using a tool like nagios or any of the commercial options for monitoring. #2 was a web-based console that shipped out of the box. The webconsole does give basic overview so you can see queues, basic destination stats, connections, network connectors, etc. Bottom line it was fairly limited, had no visualizations, and could not perform some very common and needed operations on the broker. For example, it was clumsy to move a message from a DLQ back to an original destination. However, one of the biggest motivations for moving away from this webconsole is: Every product comes with its own console! ActiveMQ’s was “just another console” .. So when you had FuseESB which contained ActiveMQ, Karaf, Felix, Camel, and potentially other JVM based apps with their own consoles, you had n consoles which becomes a huge pain.
#43 Management of your middleware infrastructure is critical. ActiveMQ had two main avenues for management and monitoring: #1 JMX through Jconsole, VisualVM, or using a tool like nagios or any of the commercial options for monitoring. #2 was a web-based console that shipped out of the box. The webconsole does give basic overview so you can see queues, basic destination stats, connections, network connectors, etc. Bottom line it was fairly limited, had no visualizations, and could not perform some very common and needed operations on the broker. For example, it was clumsy to move a message from a DLQ back to an original destination. However, one of the biggest motivations for moving away from this webconsole is: Every product comes with its own console! ActiveMQ’s was “just another console” .. So when you had FuseESB which contained ActiveMQ, Karaf, Felix, Camel, and potentially other JVM based apps with their own consoles, you had n consoles which becomes a huge pain.
#46 < compositeQueue name="MY.QUEUE"> < forwardTo > < queue physicalName="FOO" /> < topic physicalName="BAR" /> </ forwardTo > </ compositeQueue >
#47 route id="setPriority"> <from uri="broker:topic:test.broker.>"/> <setHeader headerName="JMSPriority"> <constant>9</constant> </setHeader> <to uri="broker:queue:test.broker.component.queue"/> </route>
#50 AMQP – since the first release, we’ve had lots of usecases come through and bugs that provide some hardening

ActiveMQ 5.9.x new features

More Related Content

What's hot

Viewers also liked

Similar to ActiveMQ 5.9.x new features

More from Christian Posta

Recently uploaded

ActiveMQ 5.9.x new features

Editor's Notes