[
https://issues.apache.org/jira/browse/AMQ-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870271#comment-13870271
]
Arthur Naseef commented on AMQ-4938:
------------------------------------
There are several possible desirable outcomes with REST and JMS.
Unfortunately, they are vastly different in their methodology - REST is based
on synchronous request/reply and JMS is based on asynchronous passing of
messages to consumers.
Consider load balancing in a scenario mixing REST and JMS clients. The current
model, using prefetch to push messages, provides semantics that are more "fair"
to the REST client by allowing messages to cache in the internal consumer for
that client, just as they do for JMS clients.
With that said, there is no analogous REST scenario for automatically releasing
messages when the connection closes because REST always closes the connection
after a single message while JMS holds it open indefinitely.
For more advanced use-cases, perhaps camel would be a good tool to
intelligently bridge the REST/JMS gap.
BTW, the messages stored in the consumer for REST clients aren't truly lost.
They will sit indefinitely, but once the broker restarts, they will be returned
to the broker. This is actually bad for many reasons since it really means an
idle consumer - very bad for JMS in general and activemq in particular.
Perhaps we need a REST call that will force close a consumer, or a REST call
that intentionally performs a one-shot message receive (i.e. automatically
closes the consumer after the call). Honestly, I'd prefer to put my effort
elsewhere since, as mentioned above, REST for JMS is not a great fit.
Hope this helps. Let me know your thoughts.
> Queue Messages lost after read timeout on REST API.
> ---------------------------------------------------
>
> Key: AMQ-4938
> URL: https://issues.apache.org/jira/browse/AMQ-4938
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.8.0, 5.9.0, 5.10.0
> Environment: Win32, Linux
> Reporter: Peter Eisenlohr
> Priority: Critical
> Attachments: AMQ-4938.patch
>
>
> I have been trying to send/receive messages via a Queue using the [REST
> API|http://activemq.apache.org/rest.html]. While testing I found that some
> messages got lost after a consuming request times out when no message is
> available.
> Here is a transcript of the test case I used:
> {code}
> #
> # OK: send first, consume later
> #
> $ curl -d "body=message" "http://localhost:8161/api/message/TEST?type=queue";
> Message sent
> $ wget --no-http-keep-alive -q -O -
> "http://localhost:8161/api/message/TEST?type=queue&clientId=GETID&readTimeout=1000";
> message
> #
> # OK: start consuming, then send (within timeout)
> #
> $ wget --no-http-keep-alive -q -O -
> "http://localhost:8161/api/message/TEST?type=queue&clientId=GETID&readTimeout=5000"&;
> [1] 5172
> $ curl -d "body=message" "http://localhost:8161/api/message/TEST?type=queue";
> messageMessage sent[1]+ Fertig wget --no-http-keep-alive -q
> -O -
> "http://localhost:8161/api/message/TEST?type=queue&clientId=GETID&readTimeout=5000";
> #
> # NOK: start consuming, wait for timeout, then send and consume again
> #
> $ wget --no-http-keep-alive -q -O -
> "http://localhost:8161/api/message/TEST?type=queue&clientId=GETID&readTimeout=5000";
> $ curl -d "body=message" "http://localhost:8161/api/message/TEST?type=queue";
> Message sent
> $ wget --no-http-keep-alive -q -O -
> "http://localhost:8161/api/message/TEST?type=queue&clientId=GETID&readTimeout=5000";
> {code}
> The last *wget* returns after the given read timeout without any message.
> When looking at the managament console, the message has been consumed.
> I tested this with 5.8.0 on linux as well as with 5.8.0, 5.9.0 and a freshly
> built 5.10.0 on windows.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
