[go-nuts] GKE & Issue 17066
We use GKE (Kubernetes on GCE) and have Go HTTP/2 pods running there. In front of them is a service of type "LoadBalancer". As I understand, these are nginx instances. Since this week, the error described in issue 17066 [1] is happening about 90% of the time when we connect a client via HTTP/2 (it works sporadically). This project has been running for over a year with no issues until this week. I suspect Google deployed an update or such to the load balancers. We've tried setting GODEBUG=http2client=0 (as described in package net/http doc) to use HTTP 1.1 but all we get is a io.EOF error on http.DefaultClient.Do. I'm working on a workaround, will post how we solve it. Any ideas or suggestions are welcome. [1] https://github.com/golang/go/issues/17066 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: GKE & Issue 17066
We tried: if len(os.Getenv("DISABLE_HTTP2")) > 0 { http.DefaultClient.Transport = &http.Transport{ TLSNextProto: make(map[string]func(string, *tls.Conn) http.RoundTripper), } } But the effect was the same as with GODEBUG=http2client=0, just an EOF. Will keep trying. If it is relevant we're using "golang.org/x/crypto/acme/autocert" for TLS and our service is only reachable through HTTPS. The certificate is valid and working and will not expire soon. On Friday, July 14, 2017 at 11:10:39 AM UTC+2, thwd wrote: > > We use GKE (Kubernetes on GCE) and have Go HTTP/2 pods running there. In > front of them is a service of type "LoadBalancer". As I understand, these > are nginx instances. > > Since this week, the error described in issue 17066 [1] is happening about > 90% of the time when we connect a client via HTTP/2 (it works sporadically). > > This project has been running for over a year with no issues until this > week. I suspect Google deployed an update or such to the load balancers. > > We've tried setting GODEBUG=http2client=0 (as described in package > net/http doc) to use HTTP 1.1 but all we get is a io.EOF error on > http.DefaultClient.Do. > > I'm working on a workaround, will post how we solve it. Any ideas or > suggestions are welcome. > > [1] https://github.com/golang/go/issues/17066 > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: GKE & Issue 17066
Seems to be Mac OS related. It works on Linux, every time over HTTP 1 and 2. On Friday, July 14, 2017 at 11:33:22 AM UTC+2, thwd wrote: > > We tried: > > if len(os.Getenv("DISABLE_HTTP2")) > 0 { > http.DefaultClient.Transport = &http.Transport{ > TLSNextProto: make(map[string]func(string, *tls.Conn) > http.RoundTripper), > } > } > > But the effect was the same as with GODEBUG=http2client=0, just an EOF. > Will keep trying. > > If it is relevant we're using "golang.org/x/crypto/acme/autocert" for TLS > and our service is only reachable through HTTPS. The certificate is valid > and working and will not expire soon. > > On Friday, July 14, 2017 at 11:10:39 AM UTC+2, thwd wrote: >> >> We use GKE (Kubernetes on GCE) and have Go HTTP/2 pods running there. In >> front of them is a service of type "LoadBalancer". As I understand, these >> are nginx instances. >> >> Since this week, the error described in issue 17066 [1] is happening >> about 90% of the time when we connect a client via HTTP/2 (it works >> sporadically). >> >> This project has been running for over a year with no issues until this >> week. I suspect Google deployed an update or such to the load balancers. >> >> We've tried setting GODEBUG=http2client=0 (as described in package >> net/http doc) to use HTTP 1.1 but all we get is a io.EOF error on >> http.DefaultClient.Do. >> >> I'm working on a workaround, will post how we solve it. Any ideas or >> suggestions are welcome. >> >> [1] https://github.com/golang/go/issues/17066 >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: GKE & Issue 17066
Actually, our error output is slightly different than issue 17066's. 2017/07/14 10:53:31 http2: Transport failed to get client conn for :443: http2: no cached connection was available 2017/07/14 10:53:31 http2: Transport creating client conn 0xc4200016c0 to :443 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote SETTINGS len=18, settings: ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=4194304, MAX_HEADER_LIST_SIZE=10485760 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote WINDOW_UPDATE len=4 (conn) incr=1073741824 2017/07/14 10:53:31 http2: Transport encoding header ":authority" = "" 2017/07/14 10:53:31 http2: Transport encoding header ":method" = "POST" 2017/07/14 10:53:31 http2: Transport encoding header ":path" = "/" 2017/07/14 10:53:31 http2: Transport encoding header ":scheme" = "https" 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: read SETTINGS len=18, settings: MAX_FRAME_SIZE=1048576, MAX_CONCURRENT_STREAMS=250, MAX_HEADER_LIST_SIZE=1048896 2017/07/14 10:53:31 http2: Transport received SETTINGS len=18, settings: MAX_FRAME_SIZE=1048576, MAX_CONCURRENT_STREAMS=250, MAX_HEADER_LIST_SIZE=1048896 2017/07/14 10:53:31 http2: Transport encoding header "content-length" = "141" 2017/07/14 10:53:31 http2: Transport encoding header "accept-encoding" = "gzip" 2017/07/14 10:53:31 http2: Transport encoding header "user-agent" = "Go-http-client/2.0" 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote HEADERS flags=END_HEADERS stream=1 len=212 2017/07/14 10:53:31 Unhandled Setting: [MAX_HEADER_LIST_SIZE = 1048896] 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote SETTINGS flags=ACK len=0 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote DATA stream=1 len=141 data="" 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: wrote DATA flags=END_STREAM stream=1 len=0 data="" 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: read SETTINGS flags=ACK len=0 2017/07/14 10:53:31 http2: Transport received SETTINGS flags=ACK len=0 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: read WINDOW_UPDATE len=4 (conn) incr=141 2017/07/14 10:53:31 http2: Transport received WINDOW_UPDATE len=4 (conn) incr=141 2017/07/14 10:53:31 http2: Framer 0xc4202b41a0: read RST_STREAM stream=1 len=4 ErrCode=INTERNAL_ERROR 2017/07/14 10:53:31 http2: Transport received RST_STREAM stream=1 len=4 ErrCode=INTERNAL_ERROR 2017/07/14 10:53:31 RoundTrip failure: stream error: stream ID 1; INTERNAL_ERROR 2017/07/14 10:53:31 Post https:///: stream error: stream ID 1; INTERNAL_ERROR We get INTERNAL_ERROR instead of REFUSED_STREAM On Friday, July 14, 2017 at 12:06:30 PM UTC+2, thwd wrote: > > Seems to be Mac OS related. It works on Linux, every time over HTTP 1 and > 2. > > On Friday, July 14, 2017 at 11:33:22 AM UTC+2, thwd wrote: >> >> We tried: >> >> if len(os.Getenv("DISABLE_HTTP2")) > 0 { >> http.DefaultClient.Transport = &http.Transport{ >> TLSNextProto: make(map[string]func(string, *tls.Conn) >> http.RoundTripper), >> } >> } >> >> But the effect was the same as with GODEBUG=http2client=0, just an EOF. >> Will keep trying. >> >> If it is relevant we're using "golang.org/x/crypto/acme/autocert" for >> TLS and our service is only reachable through HTTPS. The certificate is >> valid and working and will not expire soon. >> >> On Friday, July 14, 2017 at 11:10:39 AM UTC+2, thwd wrote: >>> >>> We use GKE (Kubernetes on GCE) and have Go HTTP/2 pods running there. In >>> front of them is a service of type "LoadBalancer". As I understand, these >>> are nginx instances. >>> >>> Since this week, the error described in issue 17066 [1] is happening >>> about 90% of the time when we connect a client via HTTP/2 (it works >>> sporadically). >>> >>> This project has been running for over a year with no issues until this >>> week. I suspect Google deployed an update or such to the load balancers. >>> >>> We've tried setting GODEBUG=http2client=0 (as described in package >>> net/http doc) to use HTTP 1.1 but all we get is a io.EOF error on >>> http.DefaultClient.Do. >>> >>> I'm working on a workaround, will post how we solve it. Any ideas or >>> suggestions are welcome. >>> >>> [1] https://github.com/golang/go/issues/17066 >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] I thought I understood floats...
https://play.golang.org/p/mQhfM6QgQG According to this program, the float 3.0e-324 is greater than 0.0, but 2.0e-324 is less than 0.0 I'm running into this problem in production... What causes this and what would be a strategy to remedy it? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: I thought I understood floats...
Ah, brainfart. Delete this post. On Friday, September 23, 2016 at 1:32:09 PM UTC+2, thwd wrote: > > https://play.golang.org/p/mQhfM6QgQG > > According to this program, the float 3.0e-324 is greater than 0.0, but > 2.0e-324 is less than 0.0 > > I'm running into this problem in production... > > What causes this and what would be a strategy to remedy it? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] The &(*x) idiom for copying.
https://play.golang.org/p/pjyoPX99Zr1 Taking the address of an explicit dereference has different behavior than implicitly dereferencing and taking address. Is this the desired behavior? It surprised me. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: The &(*x) idiom for copying.
Even more surprising, make this small change to the previous playground link code: func (t *T) CopyExplicitDeref() *T { x := *t return &x } Merely introducing a local variable changes the behavior of the method. On Wednesday, March 28, 2018 at 6:21:49 PM UTC+2, thwd wrote: > > https://play.golang.org/p/pjyoPX99Zr1 > > Taking the address of an explicit dereference has different behavior than > implicitly dereferencing and taking address. > > Is this the desired behavior? It surprised me. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: The &(*x) idiom for copying.
Hi. Don't worry, I do get pointers and pass-by-value. I expected the expression (*x) to yield a copy to the pointed-to value. But, as you say, that happens on assignment. On Wednesday, March 28, 2018 at 6:50:06 PM UTC+2, Devon H. O'Dell wrote: > > 2018-03-28 9:39 GMT-07:00 Devon H. O'Dell >: > > CopyExplicitDeref gets a pointer to the struct in its receiver. If you > > have a pointer to T, then taking a pointer to the dereferenced T is a > > no-op: you get the pointer of the thing you just dereferenced. Any > > statement &*whatever will always yield the value of whatever. Copy > > happens on assignment, and no assignment occurs in this statement. > > I just realized that one additional thing that might be confusing is > that you're expecting CopyExplicitDeref to get a copy of _something_ > since everything in Go is done by-value. Indeed, CopyExplicitDeref > does get a copy of something: the pointer to T. So if you change > CopyExplicitDeref to: > > func (t *T) CopyExplicitDeref() **T { > return &t > } > > and in main: > > a := &T{0} > b := a.CopyExplicitDeref() > fmt.Println(&a == b) > > you will see that it's actually the pointer that is copied. > > --dho > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: The &(*x) idiom for copying.
[...] a copy *of* the pointed-to value. On Wednesday, March 28, 2018 at 6:54:53 PM UTC+2, thwd wrote: > > Hi. Don't worry, I do get pointers and pass-by-value. > > I expected the expression (*x) to yield a copy to the pointed-to value. > > But, as you say, that happens on assignment. > > On Wednesday, March 28, 2018 at 6:50:06 PM UTC+2, Devon H. O'Dell wrote: >> >> 2018-03-28 9:39 GMT-07:00 Devon H. O'Dell : >> > CopyExplicitDeref gets a pointer to the struct in its receiver. If you >> > have a pointer to T, then taking a pointer to the dereferenced T is a >> > no-op: you get the pointer of the thing you just dereferenced. Any >> > statement &*whatever will always yield the value of whatever. Copy >> > happens on assignment, and no assignment occurs in this statement. >> >> I just realized that one additional thing that might be confusing is >> that you're expecting CopyExplicitDeref to get a copy of _something_ >> since everything in Go is done by-value. Indeed, CopyExplicitDeref >> does get a copy of something: the pointer to T. So if you change >> CopyExplicitDeref to: >> >> func (t *T) CopyExplicitDeref() **T { >> return &t >> } >> >> and in main: >> >> a := &T{0} >> b := a.CopyExplicitDeref() >> fmt.Println(&a == b) >> >> you will see that it's actually the pointer that is copied. >> >> --dho >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] A thought on contracts
>From the draft proposal I gather two open questions: - How free or restricted should contract bodies be? - How many implicit constraints can be inferred from usage? If too much syntax is allowed in contract bodies and no implicit constraints are gathered: people will copy and paste function bodies into contracts to cover all constraints. If only restricted syntax is allowed in contract bodies and a lot of implicit constraints are gathered: people will write empty contracts and hope for the compiler to pick up on all the constraints. These two questions are related. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Go’s runtime vs virtual machine
A virtual machine has its own instruction set. Go compiles to machine code for a given target (which could be a virtual machine). On Tuesday, September 4, 2018 at 12:27:49 PM UTC+2, Pablo Rozas Larraondo wrote: > > The Go documentation provides some explanation about the difference > between Go’s runtime and a virtual machine here: > > https://golang.org/doc/faq#runtime > > Does anyone can recommend a good place to learn more about this? I’d like > to better understand how Go’s garbage collector, goroutine scheduling and > stack management are handled by the runtime and how it is different from a > virtual machine. > > Thanks, > Pablo > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] A thought on contracts
If you can't use operations not explicitly stated in a contract: the more reason to copy-paste a function body into a contract. What I mean by implicit constraints is what the draft calls "implied constraints". -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] [go2go] "interface contains type constraints"
My (short) code: https://go2goplay.golang.org/p/J4Ovyt-4xXN The spec: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md The errors: prog.go2:7:30: interface contains type constraints (T, error) prog.go2:19:32: interface contains type constraints (T, struct{}) prog.go2:10:13: interface contains type constraints (T, error) prog.go2:15:13: interface contains type constraints (T, error) prog.go2:22:13: interface contains type constraints (T, struct{}) What am I doing wrong? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6941a289-94b0-4bb1-99d2-c685652e46a8n%40googlegroups.com.