-
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.
If this extension is used, expect that applications depending on proper flows of RECEIPT frames are unlikely to work as designed.
An example client that uses this extension functionality can be found here:
In order to provide a client with an alternative to implement the above described behavior, 512e8d8 was comitted.
This essentially implements a stompngo specific extension to the STOMP protocol. This extension operates per below.
The client uses SUBSCRIBE as per normal.
The stompngo client program must add a user header to the UNSUBSCRIBE for a queue. An example of such a header is:
sng_drnow:xxxx
The header key sng_drnow is meant to mean "stompngo drain now".
The header value xxxx is a numeric value which is the maximum number of milliseconds the extension will wait before assuming the queue is totally drained. The extension then sends the UNSUBSCRIBE frame as normal.
If this extension is used, expect that applications depending on proper flows of RECEIPT frames are unlikely to work as designed.
An example client that uses this extension functionality can be found here: