[
https://issues.apache.org/jira/browse/AMQ-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef updated AMQ-4938:
-------------------------------
Attachment: AMQ-4938B.patch
Attaching a more complete patch that:
* eliminates a race condition in which the servlet receives a message during a
continuation at the same time the continuation times-out leading to a lost
message
* eliminates another race condition in which a client may block longer than
necessary when a message arrives immediately after the initial receive call
fails to return a message
* prevents concurrent use of a consumer by throwing an exception on a request
to use a consumer when that consumer is already active in another request.
There is still a possible message-loss scenario that can't be fixed without a
rework of the protocol with the client. Once the servlet receives the message
and attempts to send it back to the client, if the client loses the connection
to the server, that message is lost. The only 100% reliable solution to that
is to push message acknowledgement down to the client, which opens more
potential issues.
> 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, AMQ-4938B.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)
