...
![]() Code Block |
<servlet>
<servlet-name>MessageServlet</servlet-name>
<servlet-class>org.apache.activemq.web.MessageServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>topic</param-name>
<param-value>false</param-value>
</init-param>
</servlet> |
Alternate Producing Syntax
An alternative syntax for posting is supported, using the destination URL-encoded parameter; here are some examples:
![]() Code Block |
# Send to queue orders.input:
curl -XPOST http://admin:admin@localhost:8161/api/message?destination=queue://orders.input
# Send to topic orders.input:
curl -XPOST http://admin:admin@localhost:8161/api/message?destination=topic://orders.input
|
Timeouts
When reading from a queue we might not have any messages. We can use a timeout query parameter to indicate how long we are prepared to wait for a message to arrive. This allows us to poll or block until a message arrives.
...
Obviously if your client is Java then using ActiveMQ's JMS API is the fastest and most efficient way to work with the message broker; however, if you are not using Java or prefer the simplicity of HTTP then it should be fairly efficient, especially if your HTTP client supports keep-alive sockets and pipeline processing.
Consuming
When consuming messages using the REST API, you have to keep session alive between GET requests, or you'll create a separate consumer for every request and due to prefetch limit your succeeding call will hang.
...
in the webapps/demo/WEB-INF/web.xml
Alternate Consuming Syntax
As with producing, an alternative syntax for consuming messages is also supported, using the destination URL-encoded parameter; here are some examples:
![]() Code Block |
# Send to queue orders.input:
curl -XGET http://admin:admin@localhost:8161/api/message?destination=queue://orders.input
# Send to topic orders.input:
curl -XGET http://admin:admin@localhost:8161/api/message?destination=topic://orders.input
|
Consuming without sessions
Since 5.2.0 you can use clientId parameter to avoid storing actual JMS consumer in the request session. When using this approach, you don't need to keep sessions alive between requests, you just need to use the same clientId every time.
...
