-
Notifications
You must be signed in to change notification settings - Fork 394
h2: Make requests walk away from the waiting list #3835
Changes from all commits
808c673
9200141
7d53b8b
2e9bcc3
f6ebc5a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -562,6 +562,21 @@ cnt_lookup(struct worker *wrk, struct req *req) | |
| had_objhead = 1; | ||
| wrk->strangelove = 0; | ||
| lr = HSH_Lookup(req, &oc, &busy); | ||
| if (lr == HSH_WALKAWAY) { | ||
| VRY_Finish(req, DISCARD); | ||
| AZ(req->objcore); | ||
| AZ(req->stale_oc); | ||
| VSLb_ts_req(req, "Waitinglist", W_TIM_real(wrk)); | ||
| VSLb(req->vsl, SLT_Error, "The client is going away"); | ||
| if (req->esi_level > 0) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why should we only go to VCLFAIL for subrequests? This implies that HSH_WalkAway will only ever be called as part of a broken connection, and we have to close. Could it not be useful also for a possible future waitinglist timeout feature, and we need to produce a 503?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. First, we can add a dedicated For the timeout case, we probably want to have different semantics than plainly ending the transaction. Maybe a waiting list timeout would be a deferred I must admit I don't remember precisely why we did that downstream. I think we needed this to interrupt ESI delivery and prevent it from recursing as the client is gone anyway.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's actually a comment a few lines below explaining why we fail sub-requests: /* NB: Interrupt delivery upwards to avoid engaging
* new sub-request tasks.
*/Granted, it doesn't give many details. |
||
| /* NB: Interrupt delivery upwards to avoid engaging | ||
| * new sub-request tasks. | ||
| */ | ||
| req->req_step = R_STP_VCLFAIL; | ||
| return (REQ_FSM_MORE); | ||
| } | ||
| return (REQ_FSM_DONE); | ||
| } | ||
| if (lr == HSH_BUSY) { | ||
| /* | ||
| * We lost the session to a busy object, disembark the | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -52,7 +52,7 @@ struct hash_slinger { | |
| }; | ||
|
|
||
| enum lookup_e { | ||
| HSH_CONTINUE, | ||
| HSH_WALKAWAY, | ||
| HSH_MISS, | ||
| HSH_BUSY, | ||
| HSH_HIT, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like quite the waste of memory adding 24 bytes for the list entry and the objhead reference flag on struct req. I think I prefer the original way of doing the workspace allocation, perhaps replaced/expanded with a fallback malloc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had considered this, and decided it would be simpler, especially with the generalization of the feature to include HTTP/1 too.
I can ponder something similar to what we did downstream but more general (not tied to h2 code).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just remembered why I didn't use the workspace: it is reserved for vary processing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got some results on the generalization side, but didn't manage to without allocation space somewhere. Since workspace is reserved during waiting list operations, it is either a heap allocation or preallocated storage in struct req (current solution). Another possibility could be to opportunistically allocate an "entry" for transport tracking on the workspace before the vary reservation, if the top transport has waiting list methods.
To be continued.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering that eventually both h2 and http/1 (100% of client top transports) will track requests and sub-requests in waiting lists, it would be much simpler to go with the current design and have the tracking state directly in struct req.