You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Tom Samplonius <to...@samplonius.org> on 2007/05/27 06:06:21 UTC

4.1.1 and Stomp; lost unacked messages

  I noticed some strange behavior with ActiveMQ 4.1.1 and the Stomp protocol.  When I connect, I set the ack mode to "client".  I read a message, and exit.  Since I did not ack the message, I should expect to get the same message on next execution, and I do, as long as I do an explicit disconnect.  If I just close the socket, I do not the get the message again.

  So, it is weird.  If I send a disconnect, the un-acked message is preserved.  But if the socket is just closed, the un-acked message is lost.

  This is not a good interaction for my application, as it is possible that the message consumer may die or be killed, or its  network connection may be reset, while it is processing a message.  And if the consumer does not send an ack, or send a disconnect, I could lose a message.

  How do I get the behavior I need?


  Here is the code.  If the disconnect statement is commented back in, messages are preserved:


my $stomp = Net::Stomp->new( { hostname => 'localhost', port => '61613' } );
$stomp->connect( { login => 'system', passcode => 'manager' } );
$stomp->subscribe(
      {   destination             => '/queue/vp',
          'ack'                   => 'client',
          'activemq.prefetchSize' => 1
      }
);

my $frame = $stomp->receive_frame;
print $frame->body, ".\n"; # do something here

#$stomp->disconnect;



Tom

Re: 4.1.1 and Stomp; lost unacked messages

Posted by Tom Samplonius <to...@samplonius.org>.
----- "Tom Samplonius" <to...@samplonius.org> wrote:
> I noticed some strange behavior with ActiveMQ 4.1.1 and the Stomp
> protocol.  When I connect, I set the ack mode to "client".  I read a
> message, and exit.  Since I did not ack the message, I should expect
> to get the same message on next execution, and I do, as long as I do
> an explicit disconnect.  If I just close the socket, I do not the get
> the message again.
...

  I believe this is a bug in the 4.1.1 release.  I tried a recent 4.2 snapshot, and it does not have this problem.

  Is there anylike like a beta or a release candidate coming up?  I don't want to have depend on something that doesn't change every day.  I could have picked a bad day.  Anyone recommend a particularly reliable snapshot?

Tom