Slashdot Mirror

← Back to Stories (view on slashdot.org)

Red Hat Spins Off JBoss 2.x As HornetQ

Posted by ScuttleMonkey on from the strip-mine-rename-and-release dept.

Several sources are reporting that Red Hat has spun off the 2.x release of the JBoss messaging protocol as HornetQ. The 1.x version of JBoss is still being supported in maintenance mode and will continue to be known by its original name. "HornetQ is an open source project to build a multi-protocol, embeddable, high performance, clustered, asynchronous messaging system. HornetQ is an example of Message Oriented Middleware. [...] 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 favorite JEE application server, or run it embedded inside your own application. It's up to you."

50 comments

  1. Misleading by Anonymous Coward · · Score: 3, Insightful

    What a badly written and misleading headline.

    1. Re:Misleading by Anonymous Coward · · Score: 0

      What a badly written and misleading headline.

      Kind of in keeping with the name of the product.

    2. Re:Misleading by fatp · · Score: 1

      I think it's simply wrong. I don't think anyone will think JBoss 2.x means JBoss Messaging 2.x, instead of JBoss App Server 2.x (even it is very very old)

  2. Yet another message passing system by Viol8 · · Score: 1

    Just what the world needed.

    Is there something special about this that the 101 others around can't do or is it just a Me-Too product for Redhat?

    1. Re:Yet another message passing system by nacturation · · Score: 5, Informative

      Just what the world needed.

      Is there something special about this that the 101 others around can't do or is it just a Me-Too product for Redhat?

      JBoss MQ goes back to 2002 and was renamed to JBoss Messaging and is now being renamed to HornetQ. Given that it's been around for so long, you should instead ask most of your 101 other ones why they are Me-Too products.

      --
      Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
    2. Re:Yet another message passing system by Viol8 · · Score: 1

      "Given that it's been around for so long"

      Yeah, right. Go look up the 2 main ones used in the Fortune 100s - Websphere (formally) MQ Series and Tibco EMS and see how long they've been around.

    3. Re:Yet another message passing system by Anonymous Coward · · Score: 0

      Wow, off by 99 error.

    4. Re:Yet another message passing system by nacturation · · Score: 2, Informative

      Yeah, right. Go look up the 2 main ones used in the Fortune 100s - Websphere (formally) MQ Series and Tibco EMS and see how long they've been around.

      I never claimed JBoss MQ has been around longest. Your initial statement was that there were 101 others and JBoss MQ is a Me-Too product for Redhat. Unless you can prove that there were 101 that came before JBoss MQ, your initial statement is bullshit.

      --
      Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
    5. Re:Yet another message passing system by Anonymous Coward · · Score: 0

      Hmm, maybe you should do the googling because you look less silly being argumentative when you've got your facts straight?

      Silly as in - RabbitMQ was released in 2007, and is based on a spec that only came out in 2004?

      OAQ, Solace AND JbossMQ all appeared in 2001. So those two hardly prove your point either.

      The others are older: MSMQ appeared in 1997, JORAM in 1999, ActiveMQ dates back to 1999ish but moved to apache in 2005.

      Also, it's "formerly".

    6. Re:Yet another message passing system by Anonymous Coward · · Score: 0

      I guess I should back up that 'dates back to 2001' thing since the original poster said 2002. Well, it was released in Jboss 2.2, on April 16 2001:
      http://groups.google.co.uk/group/fm.announce/browse_thread/thread/37c61f64c32a05b1/cfa9c852a1f37f7?hl=en&ie=UTF-8&oe=utf-8&q=jbossmq#0cfa9c852a1f37f7

      My bad on OAQ tho - it was in Oracle 8 (1997), as an optional extra.

    7. Re:Yet another message passing system by nkh · · Score: 1, Informative

      Why should I do the googling for you you lazy cnut?

      I wouldn't call Knuth lazy even if the 4th volume of his Art of Computer Programming is a bit late. While you wait for it, the 3rd edition of Introduction to Algorithms is available on Amazon. Please be patient!

    8. Re:Yet another message passing system by Anonymous Coward · · Score: 0

      This statement is not true...the new 2.0 version is an AMQP implementation. 2.0 is not the old JBoss messaging but a new on the wire protocol implementation of JMS... AMQP is orders of magnitude faster than the old implementation.

    9. Re:Yet another message passing system by jimmyfrank · · Score: 0

      What the fuck is a message passing system? I've been working with asynchronous messaging queuing systems for a while and have yet to work with a message passing system. Anyway, I'm not sure there are 101 different asynchronous messaging queueing platforms, maybe there are. Some of the popular ones are Websphere MQ, Microsoft MSMQ, Apache ActiveMQ, and SonicMQ. All have their pros and cons, like MSMQ only running one platform whereas IBM MQ running on several. MSMQ has message size limitations that IBM doesn't. My favorite though is Apache ActiveMQ because it has duplex connections. I'm still surprised to this day that people can't tell the difference between app servers, integration tools (BizTalk), and asynchronous message queuing tools.

    10. Re:Yet another message passing system by DragonWriter · · Score: 1

      Go look up the 2 main ones used in the Fortune 100s - Websphere (formally) MQ Series and Tibco EMS and see how long they've been around.

      Of course, those are also the reasons for all the new ones -- as asynchronous messaging becomes more important and more widely useful, event big, established customers for the big products in the field aren't happy with the existing options; after all, the AMQP protocol effort is essentially a collaboration of some of the biggest messaging users (particularly in the financial industry), and some tech firms that aren't TIBCO and IBM, to get an open protocol to better meet the customers' needs and eliminates vendor lock-in.

  3. Does this mean the end of QPID? by Anonymous Coward · · Score: 1, Insightful

    Red Hat also makes an AMQP (Another Message Queue Protocol) broker called QPid. But it seems JBoss is much, much more successful. Does the explicit message focus in HornetQ mean that Red Hat will abandon AMQP? (Ok, it's "advanced message whatever")

  4. Lets hope they fixed the major flows from 1.x by thammoud · · Score: 3, Insightful

    In 1.x, a server would hang if a client died (OS Crash, Pull the plug). That is a cardinal sin in the world of MOM. The excuse for not fixing it in 1.x was that they were using some internal networking library. 2.x looks impressive indeed, but you know what my first will be. Pull the f'ing plug.

    1. Re:Lets hope they fixed the major flows from 1.x by Hal_Porter · · Score: 4, Funny

      Heretic!

      Transaction safety is an evil practice of proprietary systems from the 1970's. It's not something we should be concerned with in the Web 2.0/Open Source world.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    2. Re:Lets hope they fixed the major flows from 1.x by Anonymous Coward · · Score: 0

      Is that right Mr Major Flow?

  5. POJO and message-oriented? by Lally+Singh · · Score: 2, Interesting

    Wow, what an incredible advancement over erlang and tuples.

    --
    Care about electronic freedom? Consider donating to the EFF!
    1. Re:POJO and message-oriented? by fartrader · · Score: 1

      Except people actually use Java /ducks

    2. Re:POJO and message-oriented? by IBBoard · · Score: 4, Informative

      And in case people wonder what POJO is (it seems to be tagged but not answered at the moment) they're Plain Old Java Objects (i.e. standard Java objects with no additional attributes or post-processing beyond what happens to any other class).

    3. Re:POJO and message-oriented? by slim · · Score: 1

      There's no reason why you couldn't mix and match. I guess the GP is suggesting that Erlang would be a better language for writing a messaging server - or perhaps he's alluding to an existing product.

      For example, WebMethods is mostly a Java product, but its message server, sold as a reliable, high performance component, is written in C. (Note: I am not endorsing WebMethods).

      So, it might well make sense to write a clustered messaging server in Erlang, accepting client connections from Java and other languages.

    4. Re:POJO and message-oriented? by Anonymous Coward · · Score: 0

      Java/ducks is a very stable product.

    5. Re:POJO and message-oriented? by Anonymous Coward · · Score: 0

      http://www.rabbitmq.com/

      An open source message queue written in Erlang. Uses the amqp open standard. There are amqp clients for Java, Python, C#, and probably several other languages.

    6. Re:POJO and message-oriented? by Anonymous Coward · · Score: 0

      That is such an obvious fan-boy statement. Done with ruby are we?

    7. Re:POJO and message-oriented? by Anonymous Coward · · Score: 0

      Nah, Ruby boys are eyeing Scala now. Erlang fetish never happened , because it's not for web apps, which is the only area people with ruby attention span can hack on.

  6. And why should we care? by Antique+Geekmeister · · Score: 1, Offtopic

    Seriously. If all it is is a 'messaging protocol', why can't we just use UUCP or, say, something whose underlying compiler is stable? I've been having tremendous issues with having to install subtlely different JVM's for different applications because they cannot keep straight where the JVM's are installed, how to name them, or whether they are compatible with one different appliations. (Sun is no help with this, by the way: the 'write once, run everywhere' model for Java has been more of a 'write once, run nowhere' one this last year due to version drift.) If I see one more application installer overwrite '/etc/profile' by manually setting JAVA_HOME to its own desired location, it's going to get ugly in my workspace.

    Java has been useful for large protocols and projects where programmers like to say "and then a miracle occurs" when they hand off processing to other programmers, but for performance sensitive, business critical, programs? I'm just not seeing the reason for it. And this particular field is suffering, badly, from having far too many "application servers".

    The one obvious advantage of JBoss is that it is LGPL. And that is not a small feature. But is it really needed? OK, so it has a Tomcat 5.5 component. Tomcat 6 has been out for years, and and Topmcat 5 should have been dropped about 2007.

    1. Re:And why should we care? by Anonymous Coward · · Score: 0, Insightful

      Do you have any idea what message passing is? Any idea whatsoever? Clearly not.

      We aren't talking about fucking emails or newsgroup postings here, for the love of God. We are talking about small messages passed within nanoseconds between highly time-sensitive componentry running on mainframes.

      The latency of UUCP is fucking massive compared to that of a good message passing engine. That said, you are right, most Java software is shit, and the message queues implemented in Java are no exception.

      The best message passing engines are implemented in pure C, and are often proprietary.

    2. Re:And why should we care? by Anonymous Coward · · Score: 0

      "We are talking about small messages passed within nanoseconds between highly time-sensitive componentry running on mainframes."

      Maybe and maybe not, rather specific case there.

    3. Re:And why should we care? by Vellmont · · Score: 1


      I've been having tremendous issues with having to install subtlely different JVM's for different applications because they cannot keep straight where the JVM's are installed

      I don't think this has anything to do with the language or the compiler, but more to do with the relationship between the OS maker and Sun. Sun only recently opened up and allowed less restrictive re-distribution of the JVM, so you'll see open source versions of Java included with linux distributions these days. Before that happened it was more customary to package up the JVM with your product (and thus your woes). Microsoft of course see themselves as a competitor to Java, so they're loathe to include a JVM in their OS.

      The other party to lay blame on is the application developers. There's no reason why they can't put looking for an existing JVM in their setup process (and many do), or if you want to do it "right" on linux, make an RPM or DEB.

      Java has been useful for large protocols and projects where programmers like to say "and then a miracle occurs" when they hand off processing to other programmers, but for performance sensitive, business critical, programs?

      You could insert any language in the world into that statement and find some truth behind it. Shit, some people use Visual Basic for "performance sensitive, business critical programs". I think those people are insane, but that doesn't mean it doesn't happen.

      --
      AccountKiller
    4. Re:And why should we care? by Anonymous Coward · · Score: 0

      From the article title to replies like this one, it's proof positive that not only do you not have to know what you're talking about to post on Slashdot, it's an active liability. It's chock full of pseudo-intellectual self-labeled geeks tripping each other to be the oh-so-cleverest, and the smartest guys in the room who scoff at everything else.

      UUCP? Rants about WORA? My god, if you were anything like an actual professional in this field, you'd be embarassed at anyone talking like this.

  7. Another name for bloatware by TheDarkMaster · · Score: 1

    Just another shinny new name for a bloated server... A Jboss server needs here one MINUTE to load. the Apache Tomcat server? Just 4 seconds


    And yes, I know the Jboss have "lots of features". But nothing I cannot make by myself as needed and using a lot less memory.

    --
    Religion: The greatest weapon of mass destruction of all time
    1. Re:Another name for bloatware by thePowerOfGrayskull · · Score: 1

      Just another shinny new name for a bloated server... A Jboss server needs here one MINUTE to load. the Apache Tomcat server? Just 4 seconds

      That's like comparing a Geo Metro to a Cadillac and complaining that the Cadillac is so damned heavy. Oh, shit. You've made me do a car analogy. I'm so very sorry. Rest assured, someone will come along and make it even worse - it's a weird compulsion people have here.

      And yes, I know the Jboss have "lots of features". But nothing I cannot make by myself as needed and using a lot less memory.

      Ahh, now I begin to see. Let me guess... you're in your early twenties, and figure that the only code that's worth shit is what you wrote yourself?

    2. Re:Another name for bloatware by Hognoxious · · Score: 2, Funny

      Just another shinny new name for a bloated server

      There has tibia better explanation than that.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    3. Re:Another name for bloatware by DiegoBravo · · Score: 1

      > A Jboss server needs here one MINUTE to load.

      I think that many people feels that a Big and Expensive (even OSS bla bla) product should take for ever to load.

      And most people didn't realize that all the apps they run just need a Web Container. Of course, there are exceptions, but apparently a lot of developers think that for whatever reason they need support for EJBs, JMS, JTA, Clustering, etc... for their JSP/JSF/Struts projects.

    4. Re:Another name for bloatware by abigor · · Score: 1

      I'm confused. What does the JBoss application server have to do with this messaging middleware product? They are completely separate.

    5. Re:Another name for bloatware by Anonymous Coward · · Score: 0

      First, JBoss is not an alternative to Tomcat. JBoss is an application server. Tomcat is a servlet container. In fact, Tomcat is an integrated component of JBoss. Of course JBoss will take longer to start than Tomcat, given that starting Tomcat is one step in starting JBoss.

      Second, this article, despite the misleading title, isn't about JBoss Application Server (which was up to version 5 last I checked, although it's been a while).

  8. Why use a language-dependent MOM? by PostPhil · · Score: 1

    I'm bewildered why "plain old Java objects" is considered a virtue, considering it still makes the middleware language-specific for something that is essentially an integration software. If all you do is Java, fine. But gambling that you'll always be married to one language seems like you're giving up too much for no gain. Perhaps developers should take a closer look at something like Advanced Message Queuing Protocol (AMQP) and implementations like RabbitMQ or Apache ActiveMQ?

    1. Re:Why use a language-dependent MOM? by Anonymous Coward · · Score: 0

      POJOs = easy integration

      Which language do you want to marry, because all MOM is written in something. Clients on the other hand...

      http://www.jboss.org/community/wiki/HornetQFeatures seems reasonable.

  9. Clearing up a few inaccuracies by Anonymous Coward · · Score: 1, Informative

    Hello all-

    Just to correct a few misconceptions / errors here:

    1) HornetQ is not a "messaging protocol" as the title states, it's a messaging system, a MoM (see http://en.wikipedia.org/wiki/Message-oriented_middleware), other examples of MoMs are WebsphereMQ, Tibco EMS, ActiveMQ etc

    2) HornetQ is a completely different project to JBoss Application Server - it shares zero code with JBoss AS. So any comments about JBoss Application Server start-up time are not relevant to HornetQ

    3) HornetQ is a rebranding of the JBoss Messaging 2.0 codebase by JBoss. The HornetQ codebase is almost completely different to JBoss Messaging 1.x and JBoss MQ codebase, so any comments about JBoss Messaging 1.x or JBoss MQ are not really relevant either.

    All of the above are actually explained in the FAQ, but I thought I'd re-iterate them here.

    Disclosure: I'm Tim Fox the project lead for HornetQ

    1. Re:Clearing up a few inaccuracies by jasenj1 · · Score: 1

      Mod parent up. I has no mod points so can't do it myself.

      - Jasen.

    2. Re:Clearing up a few inaccuracies by Tim+L+Fox · · Score: 2, Informative

      I should also add that HornetQ is released under the Apache Software License version 2.0, not the LGPL as was stated in one earlier comment.

    3. Re:Clearing up a few inaccuracies by Saija · · Score: 1

      Welcome to the new Slashdot: Even our article originating overlords are making dupes!
      Wow!

      --
      Slashdot ya no es que lo era! ;)
  10. Clearing up a few inaccuracies by Tim+L+Fox · · Score: 5, Informative

    Hello all-

    Just to correct a few misconceptions / errors here:

    (I'm reposting as first time it seems to have lost my comment)

    1) HornetQ is not a "messaging protocol" as the title states, it's a messaging system, a MoM (see http://en.wikipedia.org/wiki/Message-oriented_middleware), other examples of MoMs are WebsphereMQ, Tibco EMS, ActiveMQ etc

    2) HornetQ is a completely different project to JBoss Application Server - it shares zero code with JBoss Application Server. So any comments about JBoss Application Server start-up time don't apply to HornetQ - HornetQ starts up very fast!

    3) HornetQ is a rebranding of the JBoss Messaging 2.0 codebase by JBoss. The HornetQ codebase is almost completely different to JBoss Messaging 1.x and the old JBoss MQ codebase, so any comments about JBoss Messaging 1.x or JBoss MQ are not really relevant either, they're different systems.

    All of the above are actually explained in the FAQ, but I thought I'd re-iterate them here.

    Disclosure: I'm the project lead for HornetQ

  11. Wh.... by Frogbert · · Score: 1

    I think I speak for a great segment of the Slashdot readership when I say:

    WHAT THE FUCK DOES ANY OF THE ABOVE MEAN?!@

    Thank you for your time.

  12. So Jargon-filled, I can't understand what it is! by CAOgdin · · Score: 1

    I've been to the jboss site; I've seen the HornetQ webpages. Now, after 52 years as a sysadmin, programmer, CIO, etc. I can't figure out what it is, and why I should care. I get the sense that the jargon suggests is a way for clustered computers to exchange messages to coordinate their activities, but that's a sheer guess. Would one of you who know what this product does be so kind as to explain to me what this product does, and why I should look further into it? Sorry about this rant, but this is one of those cases where I'm sure the developers know what they're trying to accomplish, but I, as their potential user, perceive as a full description in an ancient dialect of Sanskrit.

  13. Re:So Jargon-filled, I can't understand what it is by Anonymous Coward · · Score: 0

    You have 52 years in the industry but you've never come across MQ before?