Closed film42 closed 4 years ago
When a timeout on request happens, the request method is responsible for cleaning up. The request handler will always remove the subscription handle when a message has been received.
This is interesting. In the timeout case, there is no way for the user to clean up because they do not know the subject name and dont have access to the internal request_inbox_mapping
to remove the subject name. Not sure what the best fix is? Dont need a fix for this PR, but I will file an issue.
This is interesting. In the timeout case, there is no way for the user to clean up because they do not know the subject name and dont have access to the internal
request_inbox_mapping
to remove the subject name. Not sure what the best fix is? Dont need a fix for this PR, but I will file an issue.
The nats.go client adds a timeout option and selects on both channels to always be able to cleanup before returning to the caller. It might be worth adding a timeout arg to the request function?
@davidMcneil Thank you for the great feedback. I like those ideas!
This implements the "Support improved request-reply implementation" item of the TODO list in the Readme.
This reduces the sub/unsub churn caused by a naive implementation of the request method. This is the method used in the official nats.go client.
When a timeout on request happens, the request method is responsible for cleaning up. The request handler will always remove the subscription handle when a message has been received.