[APLO-88] ACK followed by DISCONNECT Leaves Message Available

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0-beta6
• Fix Version/s: 1.0
• Component/s: apollo-stomp
• Environment: Linux, Ubuntu 11.04
• Assignee: Hiram R. Chirino
• Reporter: Guy Allard
• Created: 14/Oct/11 03:29
• Updated: 13/Dec/11 16:27
• Resolved: 12/Dec/11 23:35

Description

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:

1. ---------
   require 'rubygems'
   require 'stomp'
   #
   c = Stomp::Connection.open('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']
2. sleep 5
   c.disconnect
3. ---------

And is (usually) accompanied by:

2011-10-13 22:56:00,041 | DEBUG | Internal protocol error: message delivery acked/nacked multiple times: 1 | org.apache.activemq.apollo.broker.Subscription | 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 occur.

I do get some slightly different results with the go test bed, but let's start with this ............