Allow me to clarify. First, perhaps my statement is a little stronger than it should be - I wouldn't use it, but I can see it being used.
Here's my reasoning: * 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. There may be more issues. From my perspective, it would be best to create a real REST-based web service that uses the message bus than to use a pure REST/JMS adapter so that handling of things like possible lost messages can be defined by the web service (e.g. using CLIENT_ACKNOWLEDGE and only acknowledging the message after completing the REST-based request; perhaps caching responses in case the same request is duplicated). -- View this message in context: http://activemq.2283324.n4.nabble.com/activeMQ-topics-via-rest-missing-messages-tp4677698p4677812.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
