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

x/net/context/ctxhttp: implementation for <1.7 may not be correct #16668

Closed
lujiajing1126 opened this issue Aug 11, 2016 · 4 comments
Closed
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@lujiajing1126
Copy link

lujiajing1126 commented Aug 11, 2016

go version go1.6.3 darwin/amd64

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/megrez/Code/project/wosai/push/worker"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.6.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.6.3/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

I dont think the ctx implementation in go 1.6 is semantically correct https://github.com/golang/net/blob/master/context/ctxhttp/ctxhttp_pre17.go

It simply start a goroutine to do the request and discard response

It will send request first and the peer will receive the request and make response, which will make some mistake in some specific situations

Like a MQ server will consider A client has been received message so that the message cannot be consumed by B client who should have received this message.

consider following flow:

  1. cancel A client, but the request R is under flying, for R is a blocking request
  2. start client B and send a message M
  3. A client may have chance to receive the message M for we cannot determine who will receive the message, so i have to wait all A's requests fail then start B which may a waste of time
@bradfitz
Copy link
Contributor

I'm not sure I understand your scenario. The ctxhttp has a bunch of tests, though. Perhaps you can write a test which demonstrates how it's wrong? Or explain it in pseudo-code?

/cc @broady @okdave

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 11, 2016
@bradfitz bradfitz changed the title ctx for <1.7 implementation may not correct x/net/context/ctxhttp: implementation for <1.7 may not be correct Aug 11, 2016
@lujiajing1126
Copy link
Author

https://gist.github.com/lujiajing1126/d46af42294015274e926d52c850212d4

I wrote a server and client to reproduce the issue

It may express my idea more clearly

I mean calling cancel not really close the socket but just waits for the request done and discard the response

@lujiajing1126
Copy link
Author

Sorry I may confused about that. I used tcpdump and lsof to diagnose the network problem and I found that there may be some error at server-end. It's nothing about the ctxhttp lib.

The CLOSE_WAIT and the tcpdump logs show that the server did not response correctly

And I change my gist

@broady
Copy link
Contributor

broady commented Aug 12, 2016

Great, thanks for the follow up, @lujiajing1126.

@golang golang locked and limited conversation to collaborators Aug 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants