I’m happy to announce that JBoss Fuse Integration Service 2.0 has been released. The Fuse team has been hard at work bringing Camel 2.18, Spring Boot, to the OpenShift platform. This is the best platform to develop and operate integrations in a micro microservice architecture. It lets you create tailored containerized integration applications that package only the middleware services that you need and no more.
What is Fuse Integration Services?
Fuse Integration Services (FIS) is a distribution of JBoss Fuse that provides tooling and runtime support for creating containerized integration services on OpenShift, including
- Docker-formatted container images for a Fuse runtime
- Tooling to create, develop and build containerized Fuse applications
- Self-service deployment templates for common integration scenarios
- Native integration with OpenShift for service discovery, clustering,and configuration management
- All based on the core technologies (Camel, CXF, Karaf) available in JBoss Fuse
- Support for Fuse on Spring Boot along with the latest version of Camel (2.18).
- Completely overhauled templates and getting started experience for OpenShift.
- FIS-specific tooling added to Fuse Tooling suite for Developer Studio.
- A brand new Getting Started guide
- Alignment with Fuse 6.3 for Karaf images to ease transition for existing Fuse customers using Karaf/Blueprint-based apps.
- Uniform alignment with OpenShift source-to-image for both source and binary builds.
- Improved quality and bug fixes across the board.
Ready to get started?
Check out the official docs
I’m pleased to announce the availability of Apache Apollo 1.0. Apollo is a faster, more reliable, easier to maintain messaging broker built from the foundations of the Apache ActiveMQ project but with a radically different threading architecture which lets it scale to large number of concurrent connections and destinations while using a constant number of threads.
Yes, it supports JMS! Just download Apollo, start it up using the getting started guide and then check out the distribution’s
examples directory. Oh yeah, Apollo has great documentation!
I’ve re-run the STOMP benchmarks I covered in a previous post against the 1.0 release. The benchmark uses the STOMP protocol to build an apples to apples performance comparison between all the major STOMP servers. I’ve also built a new JMS benchmark which uses the JMS API build the same kind of performance comparisons. Both benchmarks are open source and available to be tried out on your choice of hardware. Or better yet, follow the simple instructions found in each project’s readme to run the benchmarks on EC2:
For those of you wondering why the ActiveMQ project create new message broker as a subproject, it’s because we wanted to address the shift in the processor market to multi core for the next major release. ActiveMQ currently employs complex thread locking which starts to become bottleneck as you increase the core count and you don’t end up fully exploiting the potential on large core count machines. By developing the solution as a subproject, it’s easier to explore the best options without impacting current main line development of ActiveMQ 5.x.
Now that the Apollo sub project has proven itself, I think it’s time to start integrating it into ActiveMQ. Ideally, ActiveMQ 6 switches Apollo’s messaging engine and adds/ports all the existing features we’ve come to expect out of ActiveMQ like networks of brokers and priority queues. But we should really be talking about this on the Apache mailing lists.. join me there!
ActiveMQ Apollo is a new generation of messaging broker built from the foundations of the ActiveMQ messaging broker, but using a radically different threading and message dispatching architecture. In it’s current incarnation, Apollo only supports the STOMP protocol but just like the original ActiveMQ, it’s been designed to be a multi protocol broker and in future iterations it should get OpenWire support so it can be compatible with ActiveMQ 5.x JMS clients.
The BIGGEST change in the broker architecture was a switch to a non-blocking threading model for message processing using the HawtDispatch library. This meant changing many of the APIs to using a continuation passing style so that caller never blocks on a request. The upside of the new architecture is that the most complex and brittle areas of multi-threaded code in ActiveMQ 5.x have now been tremendously simplified. Those areas are using actor style coarse grained synchronization thanks to HawtDispatch.
It is impressive how well Apollo performs. Using a little benchmarking tool, I compared the performance of Apollo and three other STOMP server implementations. The benchmark tests different combinations of consumers, destinations, producers, persistence options, message sizes for a total of 74 common usage scenarios. I ran the benchmarks on two different boxes. If you want to peek at the complete benchmark reports, see Ubuntu 4 Core report and OS X 8 Core report.
Apollo ends up doing really well in comparison to other servers in most cases but in some cases it’s just mind blowing. For example:
The scenario above is the case where you have 10 producer and 10 consumers on a single topic moving non persistent STOMP messages with a 20 byte payload. The graph shows that Apollo can easily sustain a total consumer processing rate of 1.2 Million messages per second while the closest contender could only reach about 105,000 thousand messages per second.
I’m very excited to announce that Mop 1.0 M1 has been released. Mop is one of those tools that you wish you have had years ago. Most of you probably have not heard of mop yet. Mop is:
… a small utility for executing Java programs which are stored as artifacts like jars or bundles in a Maven repository. MOP automatically deals with the following for you transitive dependencies downloading artifacts from remote repositories and caching them locally setting up your class path
It’s a wonderfully small download that weighs in at only 3.2 megs. Why don’t you try it out today?
For all of you who ran into issues with ActiveMQ 5.0.0 when running it in anger, I highly recommend you give the just released ActiveMQ 5.1.0 a try. This release focused focused on making the broker rock solid. It resolved several bugs which only reared their heads in high load situations. Memory leaks have been squashed and performance has even improved in several areas.
Even if you have not had seen any issues with your 5.0.0 installation, I’d highly recommend you upgrade to 5.1.0 to avoid running into some of the bugs that have been addressed in the release.