Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for no responders error on requests #576

Merged
merged 1 commit into from Jun 18, 2020
Merged

Conversation

derekcollison
Copy link
Member

If connected to a new server and a request is sent when there are no responders the request will return as soon as a response from the server is received. The response will have an empty payload and a 503 status.

Signed-off-by: Derek Collison derek@nats.io

Signed-off-by: Derek Collison <derek@nats.io>
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.08%) to 90.964% when pulling 585eab7 on no_responders into fc6fed8 on master.

Copy link
Contributor

@ripienaar ripienaar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

functionally seems good, I am glad we ended up somewhere where the new behaviour is opt in and seeing headers used :)

@derekcollison
Copy link
Member Author

Just to be clear it is not opt in at this time, its always on if the server supports it since we can use the header to distinguish between valid empty responses. Want to make sure that was clear in case we feel we still need to have a way to opt out.

@ripienaar
Copy link
Contributor

Sure it’s opt in as in it doesn’t affect existing code. We don’t ascribe special meaning to empty reply and the API behaves as always.

Early on we said we will always do empty reply because we think that won’t wise issues. The way it is now is much safer and those with older clients can be sure they won’t be affected

Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

)

// decodeHeadersMsg will decode and headers.
func decodeHeadersMsg(data []byte) (http.Header, error) {
tp := textproto.NewReader(bufio.NewReader(bytes.NewReader(data)))
if l, err := tp.ReadLine(); err != nil || l != hdrLine[:hdrPreEnd] {
l, err := tp.ReadLine()
if err != nil || len(l) < hdrPreEnd || l[:hdrPreEnd] != hdrLine[:hdrPreEnd] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch on not previously checking for len...

@@ -2904,6 +2915,7 @@ func (nc *Conn) respHandler(m *Msg) {

// Helper to setup and send new request style requests. Return the chan to receive the response.
func (nc *Conn) createNewRequestAndSend(subj string, hdr, data []byte) (chan *Msg, string, error) {
nc.mu.Lock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to go back and check pre-PR, that was weird how we got the lock in the caller but released in that function...

}

return nc.newRequest(subj, hdr, data, timeout)
// Check for no responder status.
if err == nil && len(m.Data) == 0 && m.Header.Get(statusHdr) == noResponders {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did check that even if m.Header is 'nil' (because there is no header), m.Header.Get() will work (returns ""), but I got concerned when I saw that line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants