activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <>
Subject [jira] [Updated] (AMQ-4938) Queue Messages lost after read timeout on REST API.
Date Tue, 14 Jan 2014 17:34:54 GMT


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:
>             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|].
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

View raw message