[ 
https://issues.apache.org/jira/browse/APLO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163186#comment-13163186
 ] 

Hiram Chirino commented on APLO-88:
-----------------------------------

The safest way for a client to shutdown a connection is to add a receipt header 
to the DISCONNECT frame and wait for the response.  That way you can be assured 
the server has received all previous frames.

That would also work even if SoLinger was set to 0.
                
> ACK followed by DISCONNECT Leaves Message Available
> ---------------------------------------------------
>
>                 Key: APLO-88
>                 URL: https://issues.apache.org/jira/browse/APLO-88
>             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 = 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']
> # 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 | 
> 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 ............

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to