I have created some Jiras to cover the feedback, see [1] for the current open Console jiras. I am going to make ARTEMIS-5406 my priority as it covers mostly improvements around address/queue navigation and management. If anyone has any more ideas as to how to improve this then let me know, or even some mockups?
Jan I didn't quite understand the following * Getting back from the list of queues to the list of addresses is only possible by clicking the Addresses panel, and that returns me back to page 1. * Navigating without the tree forces me to open the list of queues. However, some queues may have very complicated filters, so the filter column needs to stay hidden. could you provide more info and I will raise jiras. just fyi I am on PTO for the couple of weeks so won't have access to email Andy 1. https://issues.apache.org/jira/browse/ARTEMIS-5406?jql=project%20%3D%20ARTEMIS%20AND%20component%20%3D%20%22Web%20Console%22%20and%20status%20%3D%20Open%20 On Thu, 10 Apr 2025 at 13:39, Vilius Šumskas <vilius.sums...@rivile.lt.invalid> wrote: > First of all, thank you very much Andy for your hard work! Compared to > other brokers, like for example RabbitMQ or RocketMQ, or any pub/sub type > cloud based implementation, Artemis management UI is lacking so ANY > movement in that direction is much appreciated. > > Nevertheless, I think part of the feedback from Jan is valid. I could not > use the new console before it was released, as we have an internal policy > to not allow dev versions in our infrastructure, but I've been using > console on Artemis 2.40.0 for couple of weeks now I thought I will share my > wishes and nuances I've stumbled upon. Our use case is mainly to allow our > Java app developers to have an overview of the Artemis broker itself and > perform some cleanup/delete operations on addresses and queues, but I think > some points could make console more usable for everyone. > > * I'm not really missing three view of an old console. I think a tree > looses usability very quickly when you have at least few hundred queues or > more. Getting rid of it was the right choice. However, this didn't solve > another issue (which by the way was in the old console too). The issue of > requiring to navigate between addresses and queues tabs very often, even > for simple task. Let's say I want to cleanup old queues which are a left > over of a legacy JMS subscription topic. First I have to go to Queues tab, > then order by consumer count, find a queue which has 0 consumers, click on > address name of that queue to ensure that another queue for that address > exist, delete legacy queue, go back into queues tab and repeat all actions > for the next item in the list. This switches tabs at least couple of times. > I think having some kind of limited representation of hierarchy on > particular address or queue page would be very useful, and there will be no > need to move away from the tab. As an example you can see how hierarchy is > represented in RabbitMQ management UI. One queue page with bindings below > https://pasteboard.co/8jXYZ1bOYSBk.png , one exchange with all bound > queue https://pasteboard.co/B1Ln592HA6x7.png (exchange == address in > Artemis terms). > * Search and sorting options should be remembered at least for the > duration of the web session. It is a pain to do sorting option reset > essentially for every query. > * Search by "name" field and search using "contains" instead of "equals" > by default. > * There is a small UI bug where choosing a sorting or search option > doesn't remove the dropdown from the view. You have to click one more time > on the dropdown, to make it go away. > * Sorting by clicking on the column name would be nice. > * Address/Queue name in the list should be clickable and go into > particular object overview. > * Various basic operation buttons should be visible and not hidden under > "three dots" menu. Some basic operations, like queue purge, send message, > etc. could appear in the object overview window mentioned above. Now you > have to hunt for those actions partly in Artemis JMX view, partly by > clicking three dots menu. > * Support for multi-object operations would be great, like the ability to > select couple of queues from the list and delete them. Use case is simple, > find queues with most messages and delete them. My ideal process for such > case would look like this: 1) go to Queues tab, 2) click on the "message > count" column two times to sort in descending order, 3) mark, let's say, > top 4 results, 4) click "delete" button on top which is placed somewhere > near search form. > * Less padding and smaller fonts. This could be a user preference. > * Ability to display dates in ISO 8601 format. > * In Artemis JMX tree, clicking on attribute opens docked window with full > attribute description on the right, but in order to close that docked > window you have to click X symbol. It would be great if clicking the same > attribute the second time the window would be closed. > > Hopefully that's a fair feedback from me. > > -- > Best Regards, > Vilius > > -----Original Message----- > From: Andy Taylor <andy.tayl...@gmail.com> > Sent: Thursday, April 10, 2025 9:15 AM > To: users@activemq.apache.org > Subject: Re: 2.40.0 HAWTIO console design > > + 1 to all that Justin said. Just to add a little more, Jolokia polls > + all > the JMX beans regularly and this does not currently scale, once you hit a > certain number of addresses the console just hangs, most of this is just > for the JMX tree and isnt needed for the non JMX view. I am currently > working with the hawtIO team to introduce a caching mechanism to alleviate > some of this and once that is complete I will add a flag to disable the JMX > view which will in turn mean no polling is needed. This will allow the > console to scale. > > If I get time today I will go thru the bullet list raised and create some > jiras. Just fyi the design of components was really driven by what > Patternfly <https://www.patternfly.org/> exposes by default, making the > console experience the same would not be a sensible approach and would have > taken much longer. > > As always this is a community project and it would be great to have some > other folk contribute, currently it is only me and my time is limited, > although I will prioritise any issues and address them when I have time. > > Andy > > On Wed, 9 Apr 2025 at 23:43, Justin Bertram <jbert...@apache.org> wrote: > > > It's worth noting that there have been 2 independent releases of the > > console that was integrated into and shipped with 2.40.0. Both of > > these releases were announced on this list [1] [2]. Both announcements > > included a notification that it would replace the existing console. > > The first release was in early October 2024 so there's been roughly 6 > > months to test and provide feedback. > > > > I realize folks are busy, etc. My point is simply that early feedback > > was an option, and the redesign shouldn't have been a surprise. I'm > > not sure what else could have been done to make a meaningful difference. > > > > > > Justin > > > > [1] https://lists.apache.org/thread/vzw5qr4zs59lm35g99g1034jgfcynm6x > > [2] https://lists.apache.org/thread/cm6001qcmp98lpx7p1p75pc3v1l0c0yr > > > > On Wed, Apr 9, 2025 at 3:44 AM Jan Šmucr <jan.sm...@aimtecglobal.com> > > wrote: > > > > > Hello. > > > I know I may get some hate for this, but still, I'd like to ask: Is > > > the new console about to get some usability upgrades? > > > We're running 2.35.0 atm, and soon I'll be asked to upgrade to a > > > newer version. But admittedly, the new console gives me wrinkles. > > > Simply put, it's more JMX and less Artemis, and it wastes way too > > > much space for a productivity tool. > > > 2.39.0 main screen with address tree expanded: > > > https://ibb.co/JRqmmqHk > > > 2.40.0 main screen with address tree expanded: > > > https://ibb.co/svh1DFTh Are there plans to adjust the console > > > towards the previous user experience, or can I somehow revert to the > original one? > > > Thank you. > > > Jan > > > > > >
