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

HTTP outgoing queue bug fix (#2639) #3068

Closed
wants to merge 1 commit into from
Closed

HTTP outgoing queue bug fix (#2639) #3068

wants to merge 1 commit into from

Conversation

mareksrom
Copy link

This change fix bug of incorrect http outgoing queue which caused crash on assert. I think there should be some other changes to make ending of response more transparent, this change only fix the bug.

This change fix bug of incorrect http outgoing queue which caused crash on assert. I think there should be some other changes to make ending of response more transparent, this change only fix the bug.
@mscdex mscdex added the http Issues or PRs related to the http subsystem. label Sep 25, 2015
@tflanagan
Copy link
Contributor

Dup of #3059?

@indutny
Copy link
Member

indutny commented Sep 25, 2015

@tflanagan it is not a dup.

@indutny
Copy link
Member

indutny commented Sep 25, 2015

Why don't we move this:

node/lib/_http_outgoing.js

Lines 136 to 140 in 6192c98

if (data.length === 0) {
if (typeof callback === 'function')
process.nextTick(callback);
return true;
}
into the first if clause after it? So that callback won't be invoked immediately for the empty write if there is no assigned connection.

Should be way simpler than the current version of PR.

Also, please run make test to ensure that it works, and this change requires a test case as well.

Thanks for figuring it out!

@indutny
Copy link
Member

indutny commented Sep 25, 2015

I have a question, though... Does it really change anything when applied with #3059 ?

@indutny
Copy link
Member

indutny commented Sep 25, 2015

One more comment: I think if you'll make it work as I suggested in first comment - it looks like there should not be any need in #3059 anymore, as the finish event will be guaranteed to fire after prefinish. Do you think this is a correct statement?

@indutny
Copy link
Member

indutny commented Sep 25, 2015

cc @trevnorris @nodejs/collaborators

@mareksrom
Copy link
Author

You are right #3059 is solved by this. If suggested block is moved into first if after it, it will continue in last else and crash on trying to buffer empty data... we need to return true in this case but not invoke callback... is it right?

@indutny
Copy link
Member

indutny commented Sep 25, 2015

@mareksrom why will it crash? It doesn't look like it will do it. Returning true does not make sense to me, we are not going to send anything anyway.

@indutny
Copy link
Member

indutny commented Sep 25, 2015

@mareksrom one more question: why is it better than #3059 ? What else is it doing? I like the minimalistic nature of this PR, but just want to see if it fixes more issues than #3059. So far it looks like it isn't.

@mareksrom
Copy link
Author

I'm not sure, but I had it this way and maybe it crashed on writing nothing to connection or I don't know, I can try it again, maybe it was another problem... I'm going to try it...

@mareksrom
Copy link
Author

#3059 does not work... it only calls prefinish before finish, but what does prefinish? problem is that prefinish and finish should be called after socket was assigned and data were flushed, #3059 calls prefinish with finish callback in time it does not have even connection assigned...

@mareksrom
Copy link
Author

@indutny your proposal to move empty data to first if is ok... let's do it this way...

@trevnorris
Copy link
Contributor

There are style issues, but I like the approach.

@indutny
Copy link
Member

indutny commented Sep 26, 2015

@mareksrom any news? ;)

if (data.length === 0) {
if (typeof callback === 'function')
//callback cannot be called (finish) when the connection is not assigned
if (typeof callback === 'function' && this.connection)
Copy link
Contributor

Choose a reason for hiding this comment

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

connection is already asserted above.

Copy link
Member

Choose a reason for hiding this comment

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

We have a better fix, feel free to skip this PR.

Choose a reason for hiding this comment

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

We have a better fix, feel free to skip this PR.

Are you going to open another PR?

Copy link
Member

Choose a reason for hiding this comment

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

@arthurschreiber of course!

@mareksrom
Copy link
Author

@indurny what news? modification you proposed works and it can be this way, question is if there has to be all the block with check for data.length===0, without it it will also work, just less effective (useless empty write) that will also happen if we change it according to your proposal...

@indutny
Copy link
Member

indutny commented Sep 26, 2015

@mareksrom I think I have it working locally. Btw, is the email on your profile correct?

@mareksrom
Copy link
Author

@indutny ...

@indutny
Copy link
Member

indutny commented Sep 26, 2015

@mareksrom I mean github profile.

@indutny
Copy link
Member

indutny commented Sep 26, 2015

@mareksrom argh, I meant the one that you are using for commits: https://github.com/mareksrom/node/commit/192b28bf2fc688f3da9ad0caa0ecbb84efaf3330.patch

@indutny
Copy link
Member

indutny commented Sep 26, 2015

@mareksrom anyway, may I ask you to contact me by email? It is available on my github's profile page: https://github.com/indutny

@mareksrom
Copy link
Author

yes it is...

@Fishrock123
Copy link
Contributor

This isn't related to 11e4249, right?

@arthurschreiber
Copy link

@Fishrock123 It is.

@arthurschreiber
Copy link

@indutny Any news on this issue?

@vandernorth
Copy link

Will this be merged or are we still awaiting changes?

@rvagg
Copy link
Member

rvagg commented Sep 30, 2015

we'll make sure the fix gets in to 4.1.2 but that's slated for Monday so we have time to resolve outstanding concerns that this has been properly solved

@arthurschreiber
Copy link

Thanks for the update, @rvagg!

@Fishrock123
Copy link
Contributor

Fedor's modified fix(es) landed in 342c3a1...a4fa51c and released as 4.1.2, see: https://nodejs.org/en/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Issues or PRs related to the http subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants