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.

Sign up for GitHub

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

p2p: avoid spinning loop on out-of-handles #21878

Merged
merged 2 commits into from
Nov 20, 2020
+8 −3
Merged

p2p: avoid spinning loop on out-of-handles #21878

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d4af4c3
p2p: avoid busy-loop on temporary errors
holiman Nov 19, 2020
a418259
p2p: address review concerns
holiman Nov 20, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions p2p/server.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -854,13 +854,16 @@ func (srv *Server) listenLoop() {
<-slots

var (
fd net.Conn
err error
fd net.Conn
err error
tmpErrors = uint64(0)
)
for {
fd, err = srv.listener.Accept()
if netutil.IsTemporaryError(err) {
if netutil.IsTemporaryError(err) && tmpErrors < 200 {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I like this limit. The delay is OK, but the limit can be a problem: if the node runs out of file descriptors temporarily (i.e. not during shutdown), listening will not recover once it's over the threshold.

Copy link
Contributor

Choose a reason for hiding this comment

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

The solution could be to simply make the delay longer and remove the limit.

Copy link
Contributor Author

@holiman holiman Nov 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Ok, what's your preferred delay? How about starting at 10ms, then adding doubling the delay but cap the delay at 2 seconds ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think 2s is too much. It might be OK to just use a 200ms static delay here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, delay-wise, however, spitting out 5 lines of logs per second seems excessive, so we should still limit the log output to max one line per second, IMO

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, fixed, PTAL

srv.log.Debug("Temporary read error", "err", err)
tmpErrors++
time.Sleep(time.Millisecond * 10)
continue
} else if err != nil {
srv.log.Debug("Read error", "err", err)
Expand All @@ -869,6 +872,7 @@ func (srv *Server) listenLoop() {
}
break
}
tmpErrors = 0

remoteIP := netutil.AddrIP(fd.RemoteAddr())
if err := srv.checkInboundConn(fd, remoteIP); err != nil {
Expand Down