OMG! it's panic

[beaquant]

panic: send on closed channel

goroutine 57799 [running]: github.com/dgrr/http2.(*Ctx).resolve(0x40f3b6, {0xcc4820, 0xc00008a070}) /root/gopath/pkg/mod/github.com/dgrr/[email protected]/client.go:58 +0x36 github.com/dgrr/http2.(*Conn).writeLoop.func2.1({0x445d4f, 0xc000682f70}, {0xb1f200, 0xc000b03ce0}) /root/gopath/pkg/mod/github.com/dgrr/[email protected]/conn.go:414 +0x3d sync.(*Map).Range(0xc000682f90, 0xc000682e78) /root/go/src/sync/map.go:346 +0x2aa github.com/dgrr/http2.(*Conn).writeLoop.func2() /root/gopath/pkg/mod/github.com/dgrr/[email protected]/conn.go:412 +0x1bd github.com/dgrr/http2.(*Conn).writeLoop(0xc001b98b40) /root/gopath/pkg/mod/github.com/dgrr/[email protected]/conn.go:471 +0x407 created by github.com/dgrr/http2.(*Conn).Handshake /root/gopath/pkg/mod/github.com/dgrr/[email protected]/conn.go:239 +0x7b

[dgrr]

Sad story. I'll take a look as soon as I can. Thanks for reporting.

[dgrr]

Looks like there's a race condition there. The channel is closed because the response has been resolved already.

[hiqsociety]

just went through the code a bit and realised a lot of connecting points. not so simple as it is without following the whole code in detail. my limited opinion will be to use one of the following to "resolve":

1. struct a mutex
2. reference counting
3. spawn into a go routine by itself using https://github.com/panjf2000/ants
4. make a more complicated channel

i expanded my own code and used option 3. with fasthttp for other things when working with fasthttp in this kind of scenario. the cpu/mem overhead is better than go routines.

just my thoughts BUT i know u'll do better.

[gaby]

@dgrr Any updates on this?

[trajan0x]

https://github.com/diamondcdn/fasthttp-http2 Fixes this