No subject

"[...] acknowledge receipt of the frame with a RECEIPT frame which
contains the value of this header as the value of the receipt-id header
in the RECEIPT packet."

So RECEIPT frames should have "receipt-id" headers.

> Here's the sequence of interactions.  As you can see we receive a MESSAGE
> frame instead of a RECEIPT frame.  I'm lead to the conclusion that the
> STOMP connector in RabbitMQ is misbehaving?

I don't see any violation of the spec.

> CONNECT
> passcode:guest
> login:guest

As an aside, clients that rely on features defined in more recent
versions (such as "ack=client-individual") should negotiate the correct
version using CONNECT.

> CONNECTED
> heart-beat:0,0
> version:1.0
> session:session-tUmymk-YrI16_2JwFpOH7w
> server:RabbitMQ/3.1.3
> 
> --
> 
> SUBSCRIBE
> activemq.prefetchSize:1
> ack:client-individual
> destination:sis-test-queue
> 
> --
> 
> BEGIN
> transaction:session-tUmymk-YrI16_2JwFpOH7w-1
> 
> --
> 
> SEND
> destination:sis-test-queue
> receipt:session-tUmymk-YrI16_2JwFpOH7w-2
> 
> event%3Dprocess%26message%3DTHEDATA

You should add a transaction header to the SEND frame if you want to
publish transactionally.

> MESSAGE
> destination:/queue/sis-test-queue
> content-length:1052
> receipt:session-tUmymk-YrI16_2JwFpOH7w-2
> message-id:Q_sis-test-queue@@session-tUmymk-YrI16_2JwFpOH7w@@1
> 
> event%3Dprocess%26message%3DTHEDATA

How much time elapses here? If clients don't abort immediately then a
RECEIPT frame will arrive with header
"receipt:session-tUmymk-YrI16_2JwFpOH7w-2".

> ABORT
> transaction:session-tUmymk-YrI16_2JwFpOH7w-1
> 
> --
> 
> DISCONNECT

Make sure you read the section on destinations in
http://www.rabbitmq.com/stomp.html



-Emile