[progress Communities] [progress Openedge Abl] Forum Post: Using Rest With Activemq (ot)

[PhilF]

Here's a general question -- Are any of you successfully using REST to communicate with ActiveMQ? Do you have any problems with this? The background, for those who want more context: We have an ABL application that communicates with our client's software using a REST interface via PASOE. Their software is based on Apache Camel, so I suggested that they should use ActiveMQ to communicate for improved reliability. It turns out I opened a can of worms. I now need to recode our interface to speak directly (JMS) with a pair of ActiveMQ queues. I don't have a problem with that in principle. (though in practice, I am having lots of problems with that!) But it seems to me that the reason from running any MQ is that it can provide reliable communication with your legacy software -- even if you cannot recode that software. So I asked why not just use the existing REST interface via ActiveMQ, and this is the answer I got:

REST in ActiveMQ does not look like viable solution(we tested), it is not a recommended practice, for consuming messages. Blog-> http://activemq.2283324.n4.nabble.com/activeMQ-topics-via-rest-missing-messages-td4677698.html REST and JMS protocols are notably different; REST is one-message-per-connection while JMS is many-messages-per-connnection JMS subscriptions are dropped when the connection is dropped. For Topics, this means missed messages. For queues, this means less efficiency (for both client and broker) and less fairness of message delivery if both JMS and REST consumers are used. REST can lead to dropped messages; if the message is consumed by the activemq internal consumer and then the REST connection drops before the client receives that message, it will be lost. So, JMS message delivery guarantees are weakened. The REST implementation in the broker caches a consumer. Any messages prefetched to that consumer will remain stuck indefinitely until a REST client requests it. If a REST client uses the built-in session management, and the session that creates the internal consumer is removed, that internal consumer will be abandoned, leading to stuck messages. With Topics, regardless of the consumer prefetch, messages will be stored in the broker's memory for the subscription. If the REST client is lost or away for a long time, those messages could starve the broker for memory.

I confess I don't understand all of this -- partly due to my ignorance of the ActiveMQ architecture. And ultimately, it's not my place to dictate the architecture. But it doesn't feel right; if REST was a bad thing to do in ActiveMQ, I would think I'd find a lot of discussion and documentation on that. Thanks for your comments.

Continue reading...