[
https://issues.apache.org/jira/browse/AMQ-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869912#comment-13869912
]
Peter Eisenlohr commented on AMQ-4938:
--------------------------------------
So each new client ID creates a new subscription, which remains even after the
client disconnects or timeouts and will be dispatched messages if prefetch > 0.
Tested this with 3 clients (and without readTimeout), and all messages were
distributed equally. Nice.
Unfortunatelly, it's still pretty easy to provoke message loss when using an
(admitedly unreasonable) low read Timeout. But what may happen, timing-wise, in
an artifical test scenario may eventually happen in production even with
natural timeouts. And avoiding message loss is paramount, IMHO.
So here's another one:
{code}
#
# start receiving messages in background with readTimeout=1, clientId "GETID-1"
#
while true; do wget --no-http-keep-alive -q -O -
"http://localhost:8161/api/message/TEST?type=queue&clientId=GETID-1&readTimeout=1";;
done&
[1] 6040
#
# send some messages -- output is done by background receiver -- no message loss
#
for ((i=1; i<100; i++)); do curl -d "body=$i."
http://localhost:8161/api/message/TEST?type=queue; done
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85.86.87.88.89.90.91.92.93.94.95.96.97.98.99.
#
# create another subscription with clientId "GETID-2" (no messages read)
#
wget --no-http-keep-alive -q -O -
"http://localhost:8161/api/message/TEST?type=queue&clientId=GETID-2&readTimeout=1";
#
# try sending messages again -- expect to see every other message, but lots of
message loss
#
for ((i=1; i<100; i++)); do curl -d "body=$i."
http://localhost:8161/api/message/TEST?type=queue -so /dev/null; done
1.3.7.11.15.23.27.33.39.45.49.53.57.59.61.65.69.75.83.87.89.91.93.97.
# don't forget to stop background job
kill %1
{code}
Maybe it's just some timing issue which just becomes critical when there are
two instead of just one subscription. But still, with a server-side timeout,
the server should be able to tell if a message was completely delivered to a
client or not, despite the timeout.
> 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)
