New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
JBoss Announced the HornetQ project
Posted by Dionysios G. Synodinos on Aug 24, 2009
JBoss has announced the availability of HornetQ, an open source, multi-protocol, embeddable, high performance, clustered, asynchronous messaging system. The HornetQ code-base was worked on under the name JBoss Messaging 2.0 for the last couple of years.
The announcement gives more information about the nature of HornetQ:
HornetQ is designed with usability in mind: We've provided an extensive, easy-to-understand user-manual and quick-start guide and we ship with over 65 ready-to-run examples out of the box, demonstrating everything from simple JMS usage to complex clusters of servers and more exotic functionality.
HornetQ is designed with flexibility in mind: It's elegant POJO based design has minimal third party dependencies: Run HornetQ as a stand-alone messaging broker, run it in integrated in your favourite JEE application server, or run it embedded inside your own application. It's up to you.
HornetQ is designed with performance in mind: Our unique ultra-high performance journal provides never seen before persistent messaging performance. Automatically switching into native mode when running on Linux, it uses asynchronous IO to provide persistent messaging rates that can saturate the write throughput of a disk. Our pluggable transport system uses JBoss Netty out of the box to provide superb performance and scalability on the wire.
Although HornetQ can be integrated in the JBoss Application Server, it can also be run as a stand alone messaging server:
HornetQ has zero dependencies on any JBoss Application server components, in fact HornetQ core has zero dependencies on any libraries other than the core JDK!
Although HornetQ can be easily integrated in JBoss Application Server as the JMS provider, it can also be run as a fully functional completely independent standalone messaging server outside of JBoss Application Server, or it can be instantiated in your dependency injection framework of choice, e.g. Spring or Google Guice.
The project wiki holds a large list about the features that are present in the current release.
JBoss explained in the FAQ about the relation between HornetQ and JBoss Messaging 2.0:
During its development over the last couple of years the HornetQ code-base was worked on under the name JBoss Messaging 2.0
We decided to rename it and separate it as an independent project since it differs in a many ways from JBoss Messaging 1.x and we did not want to confuse the two, quite different, systems. The vast majority of the code base of HornetQ is different to the code base of JBoss Messaging 1.x
So, what happens with JBoss Messaging now? JBoss Messaging 1.x continues to be known under the name of JBoss Messaging and the project is now in maintenance mode only, with all new messaging development happening on the HornetQ project.
JBoss aims to make HornetQ the messaging provider of choice in the cloud and we'll be working on implementing a RESTful style API for interoperable messaging. HornetQ will also be implementing AMQP and native STOMP support to make it a truly multi-lingual messaging system.
HornetQ is licenced under the Apache Software License version 2.0 with the exception of a small number of files that JBoss claims were not possible to relicence and had to remain licensed under the LGPL JBoss aims to provide alternative ASL licenced versions of those files over time.
You can find more information about HornetQ on the project web site and wiki. There is also a short guide that will help you to take HornetQ for a tet drive in just a few minutes.
Dionysios G. Synodinos is a Web Engineer and a freelance consultant, focusing on Web technologies
AMQP
by
Matt Giacomini
Posted
Memory footprint is deal breaking constraint
by
imalpha os
Posted
Re: Memory footprint is deal breaking constraint
by
Dan Diephouse
Posted
Re: Memory footprint is deal breaking constraint
by
Tim Fox
Posted
Re: Memory footprint is deal breaking constraint
by
Georges Polyzois
Posted
Re: Memory footprint is deal breaking constraint
by
imalpha os
Posted
Re: Memory footprint is deal breaking constraint
by
clebert suconic
Posted
-
I'm looking forward to AMQP support. Is there any thoughts on when this will be available?
~Matt -
JBoss " has a deployment consisting of 2 large ear applications, each with 4 wars, each war with ~160 jars; and 2 small ear files, each with 1 war, each war with ~ 50 jars. (total 10 webapps). "
excerpt from www.jboss.org/index.html?module=bb&op=viewt...
Similarly, HornetQ memory defaults to 1G memory setting.
What a joke.
Please make a look at twitter's Kestrel(github.com/robey/kestrel/tree/master) before making announcements -
How can you even put Kestrel and HornetQ in the same box? All kestrel does is journal stuff to the file system and provide queue semantics. Kestrel is designed to solve one very small (but very important) problem. It's very bare bones and has no failover capabilities.
-
You are sadly misinformed.
A hornetQ core server can be started with just a single jar, and HornetQ core has *zero* dependencies on other third party jars. If you're using the netty transport, you just need the netty jar too. So I've no idea what relevance your comment about 160 jars is.
Regarding memory footprint. HornetQ is able to support queues containing terabytes of messages and also supports the fully transactional sending and receiving of multi-gigabyte messages even if the server is only running in 50MiB of RAM. The only real limit to queue size / message size is the amount of available disk space you have.
hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA...
The distribution ships with fully working examples that demonstrate huge queues and huge messages. -
Did you even bother reading the above article before making a comment like that ?
"HornetQ has zero dependencies on any JBoss Application server components, in fact HornetQ core has zero dependencies on any libraries other than the core JDK!"
What is it that you do no understand in that statement ? -
I'm sorry for offending Java community if that is the case you guys felt. I was entirely ignorant about HornetQ. It looks to me Java's concurrent programming model is bottleneck to do serious messaging middleware well, threads are simply too expensive to react. I could set up a RabbitMQ, write a client consumer/publisher program in a couple of hours, ready put into production and never worry about the stability, memory, message persistence or transaction, if we can do most of the common messaging requirements in ten thousand lines of code in other more suitable language, why do we need 2 millions lines of objects there?
-
Are you into politics or anything like that? You just keep talking in general, without making a valid point and not supporting any of your statements?
You can get started with HornetQ in less than 1 minute. You just download the zip, and run an example that is pretty simple and that's it.
So, I don't see what is your point.
7 comments
Watch Thread Reply