1

Currently I'm working on an interface to send and receive messages from an ActiveMQ instance on the network using the built-in REST interface (jolokia). Using the sparse documentation at hand I found out that we have one url named http://(server-ip):8161/api/message to both GET and POST messages on a predefined queue.

Sending works like a charm thus far, but receiving seems a bit more problematic. It creates a consumer per request which is not what I would like to have.

The documentation (http://activemq.apache.org/rest.html) tells me to keep the session alive and such, but I have no clue on how to do this. Furthermore, I cannot seem to find which parameters I can use to optimize these calls, nor what interfaces are available to connect to at all (apart of course from the api/message).

Is there any form of documentation or swagger-alike interface available at all for this? Any pointer in the right direction is appreciated.

[edit] I know of this answer: How does one enable or verify the REST interface of ActiveMQ?

Doug Dawson's question on the only answer is exactly what I was wondering as well.

Community
  • 1
  • 1
JustLudo
  • 1,690
  • 12
  • 29

1 Answers1

2

Consider the HTTP interface to ActiveMQ as a last resort, or a nice utility to read/write messages when performance or reliability is of no concern. It will not support many of the messaging semantics implemented in real message queueing protocols and won't be nearly as efficient.

If you have trouble using the AMQP or OpenWire/JMS apis because you have some JavaScript or mobile app code, then consider using WebSocket (MQTT or STOMP) instead of HTTP/"REST".

If you really want to find out the details of the "REST" interface - simply look at the code. It's not that much to read.

Petter Nordlander
  • 22,053
  • 5
  • 50
  • 84
  • Thank you for your comment. In fact, I'm currently using python and the stomp.py library, but encounter messages just (randomly) falling off and not being handled. I already feared due to the lack of documentation that this was not stable in any form or shape. I will just continue to look for an alternative or way to ensure I get all the messages (business logic in this case dictates to have absolute coverage) and leave the rest-api for what it is. – JustLudo Apr 03 '17 at 07:05
  • Ok. Not sure why stomp.py is not rocking for you. Maybe AMQP is an option to investigate? https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/book/overview.html – Petter Nordlander Apr 03 '17 at 11:28
  • The Stomp.py library is actually working just fine itself, but we have a situation where almost 1,2 GB of information came in in just 1 call. So 1 subscription received well over 100 messages, some up to 25 MB. I have also learned of the option to limit the number of messages that can be fetched in a single subscription on ActiveMQ, which I don't maintain myself. I will however also seriously look into qpid proton, since it might offer just a little more control over fetched messages. Thanks for that link! – JustLudo Apr 03 '17 at 12:21