activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From artnaseef <...@artnaseef.com>
Subject Re: ActiveMQ Console - let's get the problem defined
Date Sat, 01 Feb 2014 21:27:12 GMT
James Strachan-2 wrote
> Memory usage is important to a message broker - which has to spool to disk
> as soon as it's out of RAM - which drastically affects performance. BTW
> that 22mb turd is just the compressed disk size of the code, never mind
> the
> runtime overhead

Valid point on the use of disk space and RAM.  Note - if you continue to use
derogatory terms and criticism, I'll stop listening to your valid input. 
Nothing personal - I just dont want to be in that place.



James Strachan-2 wrote
> No one wants to maintain it for one; it's been dormant for years; plus
> it's
> kinda crappy.
> 
> Second there's a much better solution now. Though It'll probably annoy you
> if I mention it out loud.
> 
> Third, jolokia is probably enough these days for runtime sevices (nice,
> lean REST/JSON API to the mbeans). Any devops can knock
> themselves out with any script/tool/web page with that.
> 
> BTW before the Savoir/Talend zealots jump in with further conspiracy
> theories; jolokia isn't a Fuse/Red Hat project at all, we've no
> committers.
> It's just a great, lean solution to the management issue.

Got these:  Dormant.  Alternative exists (this is an external solution,
correct?).  Jolokia.



James Strachan-2 wrote
> Look closer. But to be honest the code's been neglected with little
> community for so long, folks probably stopped raising anything but bugs &
> security issues many years ago

It feels like this is close to a valid concern.  But I just don't see it. 
"It hasn't had much attention" could mean it's stable.



James Strachan-2 wrote
> The web console is the same old crap
> it's always been. I wrote quite a bit of it many years ago; I apologise
> for
> it profusely-  but it still deserves a sympathetic burial.

Why does it deserve a burial?  If it's old and unmaintained, then why is it
a pain point?  As I've mentioned before, I've used it and still use it, and
see people posting statements that they are using it too.



James Strachan-2 wrote
>> I wish that
>> passion were being put into making it better and moving it forward
> 
> 
> Didn't you spot that quite a few of us have been putting our passion into
> a
> new amazing console for ActiveMQ, based on modern lightweight
> technology - that's
> not 21Mb of compressed turd?  Or do you just discount all open source
> projects without an Apache PMC in principle without even looking?

Great!  And anyone that wants to use hawt.io can easily use it, correct? 
Why is hawt.io (or any other external console) necessarily exclusive with
the built-in console?



James Strachan-2 wrote
> When code is dying and losing its utility & before it's buried in the
> Attic, the compassionate thing to do is see if it can survive without life
> support. Moving it to a sub project seems the right thing to do. If you
> can
> attract a community around it - great, fair play to you. If not, the attic
> is ok too (most code will end up there one day, it's just a question of
> time).
> 
> Apache is all about communty and right now I don't see any around the
> old web console code. Moving it to a sub project will settle the argument
> once and for all in a fair, Apache Way. Whatever the outcome, the
> community
> wins

Isn't the console stable and just working?

Note that I'm working to consolidate the list of concerns and arguments for
needing a built-in webconsole and will share it soon.



--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677267.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Mime
View raw message