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

fix sync issues when using standalone http receivers #541

Merged
merged 1 commit into from
Jun 26, 2020

Conversation

n3wscott
Copy link
Member

fixes #537

Thanks for the repo-repo @maschmid it helped a lot to track this down.

The root cause was the function that delegated to the ServeHTTP was exiting too soon and closing the http connection, so the bindings message to event function was attempting to read the large body out of a closed http connection, throwing an error, attempting to return a 500, but unable to do that because the ... connection was already closed.

Adding a sync group to the standalone ServeHTTP method and also using sync.WaitGroup in the normal ServeHTTP to be consistent (I know, a little overkill, but I think it might be better than just a done channel. It gives options for batch mode in the near future.)

@n3wscott n3wscott force-pushed the fix-standalone-write-errors branch 4 times, most recently from b6f80bf to 96ea4d8 Compare June 25, 2020 18:48
Signed-off-by: Scott Nichols <snichols@vmware.com>
@n3wscott n3wscott force-pushed the fix-standalone-write-errors branch from 96ea4d8 to d185f6a Compare June 25, 2020 19:27
go func() {
r.p.ServeHTTP(rw, req)
wg.Done()
Copy link
Contributor

Choose a reason for hiding this comment

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

I admittedly don't have the full context just saw this floating by so apologies for likely noise :)
Can't we just call this synchronously instead of in a func? Am I missing something? Perhaps worthy of a comment so it's easier to reason about, but it's probably just me :)

Copy link
Member Author

Choose a reason for hiding this comment

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

There are internal details of the SDK that require these two parts to work in parallel based on how the bindings work is documented, so yeah the server needs to go and it will block until the receive call is finished which is the second block of blocking call, but the bug was the function can't exit until ServeHTTP has finished, which is blocked on the callback...

yikes

@n3wscott n3wscott merged commit dbeb62d into cloudevents:master Jun 26, 2020
@slinkydeveloper slinkydeveloper added this to the SDK 2.1 milestone Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"http: superfluous response.WriteHeader call" error, unreceived events when serving via http.ListenAndServe
3 participants