Skip to content
This repository has been archived by the owner on Oct 22, 2021. It is now read-only.

Improve view response errors #1

Merged
merged 4 commits into from Aug 23, 2011
Merged

Conversation

kocolosk
Copy link
Contributor

No description provided.

@kocolosk
Copy link
Contributor Author

The current patch set cleanly terminates the chunked response in case of a mid-response error, which is not what we want. Instead we want to skip the final empty chunk and ensure that the socket is closed on the way out. I think we can accomplish the latter by setting 'mochiweb_request_force_close' in the process dictionary, while for the former we need to skip the call to end_json_response somehow.

@rnewson
Copy link

rnewson commented Aug 17, 2011

Will fix; was up late.

@kocolosk
Copy link
Contributor Author

New code looks quite good. I think I'd add an access log entry in the http_abort clause which logs the usual request information but indicates somehow that the response was aborted midway through (instead of a status code, perhaps)?

"" -> {ok, Resp1};
_ -> send_delayed_chunk(Resp1, FirstChunk)
end,
send_delayed_chunk(Resp2, Chunk);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could this clause be written more simply?

{ok, Resp} = StartFun(Req, Code, Headers),
send_delayed_chunk(Resp, [FirstChunk, Chunk]);

Copy link

Choose a reason for hiding this comment

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

yup, got this straight from Paul's original, wasn't focused on brevity there. Will fix.

Robert Newson added 4 commits August 22, 2011 15:06
If we start a response too early we can't respond with errors
appropriately. This delays the start of the response until we
have heard back from the cluster that there's at least one
message to send the client.

Errors that occur before any message result in a response that
has the correct 500 status code. Errors that occur after a
response has started are handled by sending nothing and closing
the connection.

Thanks Paul Davis and Bob Dionne.

BugzID: 12438
This patch delays sending a _list response until the first row of the
view has been consumed.  Errors that occur before that event result in
a response that has the correct 500 status code. Errors that occur
after a response has started are handled by sending nothing and closing
the connection.

BugzID: 12438
@kocolosk
Copy link
Contributor Author

@rnewson, does the rebased patch set work for you? One for views introducing the setup, one for _list, one for tests, one for logging.

@kocolosk kocolosk merged commit 24108e0 into master Aug 23, 2011
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants