-
Notifications
You must be signed in to change notification settings - Fork 29
Issue 25
This section will discuss stompngo Issue 25. The original title of the issue is:
Potential blocking on unsubscribe with message in flight
A link to that issue is here:
https://github.com/gmallard/stompngo/issues/25
Suppose that N queues (say 10) are filled with messages (say 100 messages). The client wishes to:
- Read 1 message from queue 1, then UNSUBSCRIBE
- Read 2 message from queue 2, then UNSUBSCRIBE
- Read 3 message from queue 3, then UNSUBSCRIBE
- etc.
Under these conditions, an unmodified stompngo package will block / hang attempting to execute UNSUBSCRIBE.
In order to provide a client with the ability to implement the above described behavior, 9bc3158 was comitted.
This essentially implements a stompngo specific extension to the STOMP protocol. This extension operates per below.
The client must know a priori how many messages are to be received from a given queue.
The stompngo client program must add a user header to the initial SUBSCRIBE for a queue. An example of such a header is:
sng_drafter:xxxx
The header key sng_drafter is meant to mean "stompngo drain after".
The header value xxxx is a numeric value which is the number of messages to receive before beginning a draining operation.
The stompngo READER functionality keeps a running count of the messages received for each subscription. After the number specified by sng_drafter the READER routine will discard all subsequent MESSAGE frames.
Note that RECEIPT and ERROR frames are never discarded.
The client issues UNSUBSCRIBE normally.