HornetQ 2.3.0.Final Released

The HornetQ team is proud to announce the release of HornetQ 2.3.0.Final.

This includes new features such as replication, multiple backups, multiple failover, failback and stomp 1.2 support as well as many other enhancements, fixes and performance tweaks.

Thanks to all the team, Clebert Suconic, Andy Taylor, Francisco Borges, Howard Gao and Justin Bertram as well as Jeff Mesnil for his integration work and all the other contributors.

You can download it from http://www.jboss.org/hornetq/downloads.html

Onwards and upwards to 2.4.

HornetQ 2.3.0.CR2 - Pre Final now

This is it! We just release HornetQ 2.3.0.CR2 which we intend to be our last Candidate Release before 2.3.0.Final

We are already in code freeze mode, meaning we are only committing very minor things like release scripts or other minor changes.

This is a big deal for us, we have been working on this release for a while, which mainly includes replication with active sync (meaning you can add a backup to a node and it will copy the live data to the backup side).

Please give it a try, and we will work with anyone who finds an issue before final.

http://www.jboss.org/hornetq/downloads.html

HornetQ 2.3.0.CR1

HornetQ 2.3.0.CR1 has just been released

There are several bug fixes on this release and hopefully should be the pre cursor to 2.3.0.Final very shortly.

Replication now seems to be pretty stable, thanks to all who have tested it and help improve it, please let us know your experiences either via the user forum or our IRC channel and we will work hard to get Final out as soon as we can.

HornetQ Beta2 Released

We are really glad to announce our second Beta of HornetQ 2.3.

We are working like crazy to make things happen and we are more than  almost there now. We could fix a few issues on replication, and especially the way things are configured. Really thanks for our users who have helped us achieve this release, that's really helpful. On that front I would like to mention Yong Deng who did an awesome job on raising issues about replication on the Beta.


The current schedule is to release HornetQ 2.3 GA early next year. Any input on how things are going for you with replication and failover with 2.3.Beta2 will be really helpful. Our forums are more than ever open for that collaboration.

This could be the latest Beta already. Things are moving along well, and we are really excited about this progress.

http://www.jboss.org/hornetq/downloads.html

HornetQ is literally buzzing - 2.3.0.Beta Released

This is the first Beta which means we are almost at HornetQ 2.3.0.Final.

We have gone through a long refactoring process which included adding support for maven, adding replication and also the capablity of failing back to live servers.

We are in the process of pushing the new version to the JBoss AS7 master branch so look out for it in the next AS7 release or checkout from Github and give it a spin. 

HornetQ's is already supported through JBoss Enterprise Application and JBoss SOA Platforms. HornetQ 2.3.0 will be available through EAP6.1, and we are really excited about the progress we are doing.

Any feedback will be warmly welcomed.

HornetQ is buzzing, literally, so enjoy the release, video and the music:

HornetQ 2.3.0 Alpha released

This is not just a simple Alpha Release. It's a big release for us.

- http://www.jboss.org/hornetq/downloads
- http://www.jboss.org/hornetq/docs

We have done a whole refactoring on 2.2.0, where we have introduced atomic failover and lots of enterprise ready improvements, making it part of JBoss EAP and JBoss7. 2011 was a big year for us and we accomplished a lot at the HornetQ hive.

Since last year we have been working, and investing our resources on making replication to happen, and we didn't want just a simple replication working. We wanted replication with FailBack, and also atomic failover.

So, 2.3.0.Alpha is out now, and the only reason we called it Alpha is because it's the first, very first version of replication with failback. It should be very functional already and we would appreciate feedback about its functionality.

So, here are the enhancements we have made on this release.


- The project is now 100% maven based.

We had gone through some major refactoring and reorganization of the source code to make this happen. Maven can be a burden and every maven hater will understand what I mean, but Maven has made us to organize our source code better and make it more modular. This effort is paying off now.

- Separate jar file for the journal.

If you just need a transactional journal, you can use this jar and use just the Journal alone. It's a very fast journal after all.


- Failback and Failover with replication

Failback by itself is a nice innovation on the open source messaging space. That means you can add a server back and the data will be copied over to the new server.

- Cloud discovery support

This version now also includes cloud ready discovery support, based on JGroups 3.0.10, which can work with lots of cloud providers out there.


And of course 2.3 has all the enhancements and fixes we have done on HornetQ 2.2 along the way. So, we are calling 2.3.0.Alpha because replication still under works. But this is a very good achievement for us.


Thanks for the HornetQ team (Francisco Borges, Andy Taylor, Howard Gao, Justin Bertram, Jeff Mesnil and Clebert Suconic) and contributors like  Tomohisa on this achievement.


Full speed ahead on 2.3.0.Final now. We should have more releases often this year until we reach Final/GA. Any feedback is always welcome on making HornetQ 2.3.0 ready

Running a HornetQ Server with Maven

As part of our ongoing efforts to simplify using HornetQ we decided to Mavenize the HornetQ examples. Part of this process was to write something that would automatically start (and stop) a HornetQ server, we decided that writing a Maven plugin to do this would be the simplest way.

Once I had written it I realised that this may be useful to other people so we have created a maven-hornetq-project in github and released the first version which is available in the JBoss repository.

I'll discuss here how to configure a simple maven example that will start a HornetQ server, run a JMS Client and then stop the server.

The plug info you need to add to your build plugins is as follows

<plugin> 
   <groupId>org.hornetq</groupId>
   <artifactId>hornetq-maven-plugin</artifactId> 
   <version>1.0.0</version>
   ..............

After that there are 3 possible execution goals to choose from:

The Start Goal

This Goal basically starts the server, a typical configuration would look as follows:

<execution>
   <id>start</id>
   <goals>
      <goal>start</goal>
   </goals>
   <configuration>
   <fork>false</fork>
   <waitFor>false</waitFor>
   <hornetqConfigurationDir>myConfigurationDir</hornetqConfigurationDir>
   <useJndi>true</useJndi>
   <jndiHost>localhost</jndiHost>
   <jndiPort>1099</jndiPort>
   <jndiRmiPort>1098</jndiRmiPort>
   <systemProperties>
      <property>

         <name>build.directory</name>
         <value>${basedir}/target/</value>
      </property>
   </systemProperties>
   </configuration>
</execution> 

The Following table explains what each configuration element is used for:

name	description	default
fork	Whether or not the server is forked in a new process, if false the server will be started in the same vm as the mvn process although it will have its own classloader. If you are running multiple servers or want some isolation then you should set this to true.	false
waitFor	Whether or maven should wait until the server has been stopped before returning from the goal, i.e. if set to true maven will just execute the goal and then block.	false
hornetqConfigurationDir	Where the server should pick up its configuration files from, i.e. hornetq-configuration.xml	empty
useJndi	Whether or not a JNDI server will be started.	true
jndiHost	The Host Name that the JNDI server will bind to	localhost
jndiPort	The port that the JNDI server will bind too	1099
jndiRmiPort	The RMI port that the jndi Server will bind too	1098
systemProperties	Any System properties you want to set before starting the server. useful when using properties in configuration files.	empty

The runClient Goal

The runClient goal will basically run any standalone java client and is configured like so:

<execution>
   <id>runClient</id>
   <goals>
      <goal>runClient</goal>
   </goals>
   <configuration>
      <clientClass>org.hornetq.jms.example.QueueExample</clientClass>
         <args>
         <param>jnp://localhost:1099</param>
      </args>
   </configuration>
</execution>

The Important element here is the clientClass, this basically configures which java class you want to run. The Client also supports setting System properties.

NB You can also configure the normal maven java plugin to run as well as an integration test but since it is sometimes difficult in maven to configure the order of executions between different plugins this makes it easier.

The Stop Goal

The Stop Goal basically does what it says, its stops the HornetQ Server and is configured like so:

<execution>
   <id>stop</id>
   <goals>
      <goal>stop</goal>
   </goals>
   <configuration>
      <hornetqConfigurationDir></hornetqConfigurationDir>
   </configuration>
</execution>

It is important here that you configure the stop goal with the same configuration directory as the start goal.

Configuring the Dependencies

The following dependencies are required to run the HornetQ plugin, the important thing to remember here is that these must be placed in the plugin its self and not the poms main dependencies. Most later versions of HornetQ are supported but I would suggest using the latest and greatest. These would look something like:

<dependencies>
   <dependency>
     <groupId>org.hornetq.example</groupId>
     <artifactId>hornetq-jms-queue-example</artifactId>
     <version>${project.version}</version>
   </dependency>
   <dependency>
     <groupId>org.hornetq</groupId>
     <artifactId>hornetq-core</artifactId>
     <version>2.2.14.Final</version>
   </dependency>
   <dependency>
     <groupId>org.hornetq</groupId>
     <artifactId>hornetq-jms</artifactId>
     <version>2.2.14.Final</version>
   </dependency>
   <dependency>
     <groupId>org.jboss.netty</groupId>
     <artifactId>netty</artifactId>
     <version>3.2.3.Final</version>
   </dependency>
   <dependency>
     <groupId>org.jboss.javaee</groupId>
     <artifactId>jboss-jms-api</artifactId>
     <version>1.1.0.GA</version>
   </dependency>
   <dependency>
     <groupId>org.jboss.naming</groupId>
     <artifactId>jnpserver</artifactId>
     <version>5.0.3.GA</version>
   </dependency>
</dependencies>

One important thing to note here is that the first dependency is needed for the runClient goal and in this case is actually itself, i.e. the group id and artifact id of the same pom.


All the JMS examples currently in the HornetQ master branch at github which you can use as a reference, the snippets in this post come from the JMS queue example.