[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.
