activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guy Allard (Commented) (JIRA)" <>
Subject [jira] [Commented] (APLO-88) ACK followed by DISCONNECT Leaves Message Available
Date Sun, 04 Dec 2011 19:00:40 GMT


Guy Allard commented on APLO-88:

After some more experimentation and thought, it appears what is documented to date does not
give a totally correct picture.

FWIW, this does still occur with build apache-apollo-1.0-20111203.032948-211-unix-distro.tar.gz.

More experimentation seems to indicate that this is not triggered solely by:


but rather by:

- socket close/teardown immediately initiated by the client

If a pause (exact timing not reliably determined) is inserted between DISCONNECT and socket
close, the issue does not occur.

> ACK followed by DISCONNECT Leaves Message Available
> ---------------------------------------------------
>                 Key: APLO-88
>                 URL:
>             Project: ActiveMQ Apollo
>          Issue Type: Bug
>          Components: apollo-stomp
>         Environment: Linux, Ubuntu 11.04
>            Reporter: Guy Allard
>         Attachments: aplo-88-log.txt
> An ACK (client mode) followed by a DISCONNECT with no wait time between the frames appears
to leave message on the queue.
> I am seeing this with apache-apollo-1.0-20111012.032531-204-unix-distro.tar.gz and at
least one previous snapshot.
> I stumbled on to this while working on a new 1.1 client in go.  It occurs with either
a 1.0 or 1.1 connection.  The go code is very raw and not publicly available yet.
> However it recreates with 1.0 using the Ruby stomp gem.  Code to recreate:
> # ---------
> require 'rubygems'
> require 'stomp'
> #
> c ='my', 'mypw', 'localhost', 62613) # Apollo is here
> c.subscribe "/queue/rtest.01", :ack => :client
> c.publish "/queue/rtest.01", "a simple message"
> msg = c.receive
> c.ack msg.headers['message-id']
> # sleep 5
> c.disconnect
> # ---------
> And is (usually) accompanied by:
> 2011-10-13 22:56:00,041 | DEBUG | Internal protocol error: message delivery acked/nacked
multiple times: 1 | | hawtdispatch-DEFAULT-1
> in apollo.log
> Calling 'flush' on the socket seems to have no affect (in either Ruby or go).
> If you uncomment the 'sleep' in the above Ruby code, the problem will (usually) *not*
> I do get some slightly different results with the go test bed, but let's start with this

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message