[ 
https://issues.apache.org/jira/browse/AMQ-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arthur Naseef updated AMQ-4938:
-------------------------------

    Attachment: AMQ-4938.patch

Attached is a patch that eliminates the erroneous consumption; the problem is 
that the continuation defined for the web request times out, but the 
availableMessageListener for the consumer is never updated with that fact.  So, 
when the next message comes in, the listener consumes it with the intent that 
the continuation of the web request will receive it.

I'm going to review this code more carefully for race conditions.  I'm 
convinced there are races on the use of MessageConsumer's if more than one web 
request comes in for the same consumer (e.g. using the same clientId).  There 
may be more, including in this patch.

> 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)

Reply via email to