Server should send a RECEIPT frame on a SEND that asks for one.

[jonathanstowe]

I found this when testing the noddy server example against a JMS client library.

The client wasn't completing the sending because the RECEIPT from wasn't being received from the server (which then led me to believe there was a bug in the JMS code.)

RECEIPT is specified this:

RECEIPT
A RECEIPT frame is sent from the server to the client once a server has successfully processed a client frame that requests a receipt. A RECEIPT frame MUST include the header receipt-id, where the value is the value of the receipt header in the frame which this is a receipt for.

RECEIPT
receipt-id:message-12345

^@
A RECEIPT frame is an acknowledgment that the corresponding client frame has been processed by the server. Since STOMP is stream based, the receipt is also a cumulative acknowledgment that all the previous frames have been received by the server. However, these previous frames may not yet be fully processed. If the client disconnects, previously received frames SHOULD continue to get processed by the server.

For our purposes we can take "client frame has been processed by the server" to mean it has has successfully been parsed and placed on the messages supply.

[jonathanstowe]

To keep things consistent we should also make the client send 'receipt aware' as well. This probably wants to be done on both a per-connection (as an attribute of the Stomp::Client,) or per-request basis. In both cases if the receipt has been requested then the Promise returned by send shouldn't be kept until the receipt is returned. It doesn't seem that the specification addresses what a client should do if a receipt isn't received but there probably be a timeout with a sensible default after which the Promise is broken. It would be for the application design to determine what to do in this case.

[jonathanstowe]

Additionally the client may send a 'receipt' header in any frame other than a CONNECT so the server should be wired to respond to any frame with a RECEIPT (again the specification is vague on what the behaviour should be if this isn't received.)