If you think have found a bug or other issue with HornetQ, here's a quick guide about how to go about reporting it.

1) Many bugs turn out to be configuration issues or misunderstandings of how to use the software. So first please read the relevant chapters in the user manual thoroughly.

2) Have a look through the user and development forums to see if other users have reported similar things. Many issues can be solved by looking at recent posts in the forums.

3) Other bugs commonly turn out to be anti-patterns. We describe some common messaging anti-patterns in the performance tuning section of the user manual. Please read this thorougly too.

4) Now, you're pretty sure you've configured the system properly and you're not implementing an anti-pattern, so perhaps you have found a real bug.

The bug might already been a known bug, so first, always look in JIRA to see if there's already a filed report for this issue. Quite often we experience different users reporting the same issue more than once, any subsequent reports for the same issue will be rejected as duplicates.

To save yourself some time in writing that report, make sure it doesn't already exist.

HornetQ JIRA is here: https://jira.jboss.org/jira/browse/HORNETQ

Click on the "roadmap" tab to see the list of issues against their respective releases.

5) If the bug isn't already reported in JIRA, make sure you're using the latest version of HornetQ.

We don't spend time debugging old versions of HornetQ if the bug no longer occurs in the latest version.

If you file a JIRA bug report against an older version of HornetQ we'll just tell you to first see if it occurs in the latest version.

6) If the bug isn't already in JIRA and still occurs with the latest version of HornetQ, then the next thing you need to do is to replicate the issue with a simple self contained program or JUnit test.

Please make sure the test program is written in Java, not Scala, Ruby, Python or whatever the latest cool script is. This isn't because we're stupid, or Java bigots. It's just because we have very limited time and resources, and need to triage a lot of issues, many of which turn out to be non issues. Having to install x, y, z just to replicate an issue, may mean the issue is rejected.

We can't debug issues that only occur with your own large application, or third party software such as Spring, Mule or some other software.

If you file a JIRA that requires us to install and debug x other third party pieces of software your report will probably be rejected.

We just don't have the resources to deal with issues in that way.

The onus is on the user to replicate the issue in a simple self contained program.

7) You've now created a simple self contained program that replicates the issue, so you can now create a new JIRA report in JIRA https://jira.jboss.org/jira/browse/HORNETQ

Please fill in the description appropriately, attach your simple test program that replicates the issue and give a detailed description of how to run the program.

8) The issue will get prioritised and someone from the development team will look at your issue in due course.

We normally deal with real issues very quickly but don't expect instant results. Remember, you are getting this service for free so don't get greedy, rude or impatient - this will only make us not want to deal with you issue!

If you want guaranteed response times - buy a support contract!