[rabbitmq-discuss] stomp+ssl message send works, receive hangs after around 200-300 messages

Mon May 28 11:55:37 BST 2012

(Posting on Rabbit-Discuss for tracking.)

On 28 May 2012, at 07:39, Michael Justin wrote: 
> Thank you for this important information, as I have accidentally found a
> problem in one users code where messages are not ACKed where they should
> have been. (The code uses transacted sessions).

Aha!  Serendipitous.

Could you try reverting to prefetch=1 with this user's code fixed? If it
works, it would confirm our understanding of your symptoms, and it would
> not< be related to our own discovered bug.

Thanks,
Steve Powell  (a happy bunny)
----------yet more definitions from the SPD----------
corrugate (n.) T.V. soap scandal.
olympic (n.) A camp road-digger.
jamboree (n.) A conserve made from French cheese.

On 28 May 2012, at 07:39, Michael Justin wrote:

> Am 24.05.2012 18:08, Steve Powell wrote:
>> Michael,
>> 
>> Thank you for the further information, this has got us a bit puzzled.
>> 
>> It was a long shot, and my colleagues don't think that ACKs ought to
>> have been blocked, but I'm glad you at least have a work-around. Are the
>> SUBSCRIBER STOMP clients SENDing anything (or writing other things) on
>> the same connection, by any chance?
> 
> In my local tests there was one connection for sending messages and a separate connection for receiving them, the receiver used client side acknowledgment so there was the ACK frame per messages sent, no other SEND frames on this connection.
> 
> 
>>> Setting prefetch-count=2 fixed it, many thanks ! Could this also affect
>>> transactions, where a commit is sent instead of ack frames?
>> 
>> If it is the problem I think it is, then yes, but your question makes me
>> wonder if you remember that ACKs are transactional, not the consuming of
>> the messages, so you should not think of commit as doing an implicit
>> ACK: it doesn't. In particular, rollback does not re-queue un-acked
>> messages. Rollback will 'undo' any acknowledgements made in this
>> transaction (and, in RabbitMQ, any rejects, too). I'm sure you know
>> this, but your use of the word 'instead' got me worried. :-)
> 
> Thank you for this important information, as I have accidentally found a problem in one users code where messages are not ACKed where they should have been. (The code uses transacted sessions).
> 
> Regards
> -- 
> Michael Justin
> habarisoft - Enterprise Messaging Software for Delphi
> http://www.habarisoft.com/