HornetQ roadmap

[fuinhaazul]

Hi there!

Anybody knows the situation of hornetq?

I know that version 2.4 has been released a couple os days ago, but the features released where more focused on Wildfly compatibility and JMS 2 compatibility.

One of the features Im really ansious is [HORNETQ-248] Web based admin console for HornetQ - JBoss Issue Tracker  .

     This feature can make the HornetQ use more easy.

Another one is [HORNETQ-302] Consider allowing creation of destinations via the pure JMS API - JBoss Issue Tracker

     The management API is great, but is really hard for begginers, reason that keep then away from hornetq.

Another thing is that roadmap is oudated:

Roadmap

Thanks!

[clebert.suconic]

We are currently working on cloud support, including scale down, AMQP and colocated topology..

now we are not sure how we are going to call that release yet... will let you guys know soon

[jbertram]

One of the features Im really ansious is [HORNETQ-248] Web based admin console for HornetQ - JBoss Issue Tracker  .

Have you tried JConsole (or any other JMX management tool) as a GUI tool for administration?  What specifically would a web-based GUI do to make HornetQ easier to use?

[fuinhaazul]

Yes, JConsole is usefull, but is not easy for common users that only want to know if their messages is being consumed by his clients. And sometimes, there is no visual environment. I know that I can connect remotely, but almost ever, the customers dont have ports opened on their operational system, and they make a lot of questions when you ask for it.  Things like this, a simple web page could solve.  Another thing is the possibility to create queues and topics from the admin page. Much better then finding some xml file to include the queue dont you think?

For me, comming from anothers JMS providers, the absence of a web admin system is really strange.

Another problem that I had was when a customer queue had A LOT of messages. The producers created a lot of unecessary messages and when I tryed to use the removeAllMessages method ( or something like that) i received an OutOfMemoryException .. Well. The solution was to delete de data folder and start from the beggining.  But this was on 2.2 version i think.  That day i had to use the jconsole on a remote windows machine to connect to hornetq on a linux server on that network.

Thanks for the anwers and the interest!

[jbertram]

Yes, JConsole is usefull, but is not easy for common users that only want to know if their messages is being consumed by his clients. And sometimes, there is no visual environment. I know that I can connect remotely, but almost ever, the customers dont have ports opened on their operational system, and they make a lot of questions when you ask for it.

Anybody who administers Java applications should understand the role of JMX in application management.  After all, it is the standard, built-in way Java has chosen to expose management functionality, and it's been around since Java 5 (released almost 10 years ago now).  JConsole and VisualVM are both shipped with modern JVMs and are 2 two of a number of tools which can be used to manage a stand-alone HornetQ server.

Things like this, a simple web page could solve.  Another thing is the possibility to create queues and topics from the admin page. Much better then finding some xml file to include the queue dont you think?

Including a web server (and likely a servlet container as well) in HornetQ would add weight to the distribution and introduce potential security vulnerabilities.  In my opinion the benefits of implementing a web console do not outweigh the detriments (e.g. development effort, increased runtime complexity, increased security risk, etc.) especially when considering that basically everything that would be exposed via the web console is already available via JMX.

Furthermore, you can set up something like Hawt IO to serve as a web front-end for the HornetQ JMX beans if you like.

Another problem that I had was when a customer queue had A LOT of messages. The producers created a lot of unecessary messages and when I tryed to use the removeAllMessages method ( or something like that) i received an OutOfMemoryException .. Well. The solution was to delete de data folder and start from the beggining.  But this was on 2.2 version i think.  That day i had to use the jconsole on a remote windows machine to connect to hornetq on a linux server on that network.

Based on your description here it sounds like the JVM was teetering on the verge of an OOME because of the large volume of messages and when you invoked removeAllMessages the extra memory required by that operation pushed the JVM over the edge.  I recommend a few things here:

1. upgrade to a later version of HornetQ (e.g. 2.4.0.Final)
2. increase the heap size of the JVM
3. configure paging so as to avoid this scenario
4. put checks into the application to catch run-away producers or dead/inactive consumers

[fuinhaazul]

Anybody who administers Java applications should understand the role of JMX in application management.  After all, it is the standard, built-in way Java has chosen to expose management functionality, and it's been around since Java 5 (released almost 10 years ago now).  JConsole and VisualVM are both shipped with modern JVMs and are 2 two of a number of tools which can be used to manage a stand-alone HornetQ server.

Yes, I agree that is important for people know how to administer java applications, but at least at the projects I was involved, i couldnt find a system administrator with this skill. Normally they are good at Linux administration or they are DBAs.

Including a web server (and likely a servlet container as well) in HornetQ would add weight to the distribution and introduce potential security vulnerabilities.  In my opinion the benefits of implementing a web console do not outweigh the detriments (e.g. development effort, increased runtime complexity, increased security risk, etc.) especially when considering that basically everything that would be exposed via the web console is already available via JMX.

Maybe now with undertow the weight could be reduced? Of course, introducing a web interface security problems could appear, but if the admin console was exposed by default only to the local machine? Is up to the users decide if they want this risk. Not all projects are large projects, in my case, most of the projects work on a secure network with no contact with internet.

  And yes. Everything is exposed to JMX, but is not easy to find the really the important methods that a simple user need to use. Create and destroy queues (durables mainly) , count results... I´m saing that because I was asked a LOT about a web interface to do exactly this.

Furthermore, you can set up something like Hawt IO to serve as a web front-end for the HornetQ JMX beans if you like.

Thanks! I will look at it.

3 - configure paging so as to avoid this scenario

Well... I was paging in that day.

In fact, I could not find any project that i could use a non persistent and non paging queues. The queues must stay there for months until the clients connect and consume everything. Sometimes are records that are transferred between databases, sometimes are software upgrades that must be delivered in the same order they are posted. Because of that, delete the data folder is really painful.

Thanks for the answers. I will continue to follow the releases.

[jbertram]

Is up to the users decide if they want this risk.

I think that's a bit simplistic.  Any risk for the user is also risk for the developer(s) which multiplies over time.  If something is broken or vulnerable in a 3rd-party web server and/or servlet container that we package and ship then we as developers inherit its problems.  Time spent getting problems fixed in an upstream project we depend on and/or packaging a new version of it, etc. and then releasing a new version of HornetQ with the fix(es) is a lot of time wasted when we could be doing something more productive.  And if a developer's time is wasted then that impacts all users.

And yes. Everything is exposed to JMX, but is not easy to find the really the important methods that a simple user need to use. Create and destroy queues (durables mainly) , count results...

Really?  All you need to do is connect to the JVM with JConsole or VisualVM and you get a nice, clean hierarchical view of all the HornetQ JMX beans.  All of the management operations are clearly labelled, the input parameters are named, and there are even tool-tips to briefly explain what the method does.  In a few clicks I can connect and create a new destination or destroy an existing one.  I can descend into a tree where all the queues are listed and see relevant statistics on them.  I'm struggling to see how a web interface could be much simpler (or responsive) than that.

Well... I was paging in that day.

Paging isn't as simple as either paging or not paging.  Furthermore, just because you are paging doesn't mean you won't run out of heap space.  You have to analyze your use-cases and tune paging according to the behavior your want.  It's possible such tuning could have avoided the OOME.

In fact, I could not find any project that i could use a non persistent and non paging queues. The queues must stay there for months until the clients connect and consume everything. Sometimes are records that are transferred between databases, sometimes are software upgrades that must be delivered in the same order they are posted. Because of that, delete the data folder is really painful.

It sounds to me like your use-case isn't terribly well suited for a message broker.  If you have large amounts of data that needs to be persisted for a long time (e.g. months) then you might consider a different approach (e.g. using a database directly).  HornetQ paging is a palliative. 

In any event, we're way off-topic at this point.

[vennelamqwf]

This thread was very helpful

Both JConsole and hawtio are excellent

I have been playing around with hawtio for a week now but didn't realise I could send messages.

Thanks for the information