On Fri, Apr 17, 2015 at 11:53 AM, Tim Bain <tb...@alumni.duke.edu> wrote:
> If you embed it in your app, then you lose the ability to cycle your app > without taking down your broker (which is a bad thing if you use > non-persistent messaging as we do). Oh. to clarify. I built our own foo-activemq service. So it benefits from our framework but it’s pretty stand alone. This way I can embed my own stuff alongside activemq but you can also reboot it. We have like 15 daemons anyway and that code is pretty reliable so maybe this would be harder for others. > With that being said, I'd be really interested in the ability to expose a > RESTful API around the broker so you can get JMX stats faster than JMX will > allow, because we've been hampered by how slow JMX is. Jolokia is looking pretty good so far. I know there was discussion about not embedding hawt.io by default in ActiveMQ but maybe that wasn’t the best strategy. I’m not sure anyone actually uses the current web UI but maybe I’m wrong. > We're trying to > poll dozens/hundreds of destination/consumer/producer MBeans every > second to log out status (to help us look for sources of lag within the > system), and JMX is completely unable to keep up, so we'd love a better > option. Jolokia is looking decent. I didn’t test it in our environment because for one of our uses I only needed two fields and I might even decide to go with a binary protocol. I want to fetch it rapidly… like once every 500ms so I can quickly see if any of our queues have a message and then start subscribing to them. > I'm not sure if that would be done by embedding ActiveMQ within an > app that provides only that RESTful API or by rolling the API into the core > broker executable, but if you're still thinking of open-sourcing that code > (whether as part of the ActiveMQ project or as a companion project), we'd > be interested in using it. > Ug. I’m totally fine with OSSing things but the problem we have now is that our app is very modular, but we’re not easily able to break off sub-modules and publish them because git submodules are evil and broken and just don’t work. We git a lot of rapid iteration by having all the same code in the same repository and just rapidly iterating. the problem is that it means we can’t easily contribute back to Open Source. I will need a way to fix this in the future though. That clearly doesn’t scale. -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts> <http://spinn3r.com>
