[
https://issues.apache.org/jira/browse/FLUME-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916340#comment-13916340
]
Jeremy Karlson commented on FLUME-2333:
---------------------------------------
I understand your concerns. I did think about the error conditions and
considered something like what you proposed. In the end I submitted it as-is
because of this:
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29
My understanding of the servlet spec is that the handler can write anything it
wants to the response stream. In the event sendError() is called, that
response is discarded. (As long as flush() was not previously called on the
stream, which I don't think they should be doing anyway.) So the transactional
error cases end up doing this:
* passes the input and output to the handler
* assuming the events are well formed, handler generates a list of events and
writes a success response to the output
* source attempts to write events to the channel and fails
* source calls sendError() on the output, which aborts any response the handler
may have made and returns a HTTP error code
In my mind, this is actually a feature - clearer separation of concerns. The
handler is only concerned with receiving and generating events. It does't
know, and doesn't have to know, that something went wrong in the channel
writing. That is returned as a 500 (server error) or 503 (server unavailable),
which I think actually makes sense... It's not an error internal to the
handler protocol, it's something in the server (Flume).
I suppose I should have mentioned the "don't call flush()" thing in the doc
update.
What do you think?
> HTTP source handler doesn't allow for responses
> -----------------------------------------------
>
> Key: FLUME-2333
> URL: https://issues.apache.org/jira/browse/FLUME-2333
> Project: Flume
> Issue Type: Improvement
> Reporter: Jeremy Karlson
> Assignee: Jeremy Karlson
> Attachments: FLUME-2333.diff
>
>
> Existing HTTP source handlers recieve events via a HTTPServletRequest. This
> works, but because the handler doesn't have access to the
> HTTPServletResponse, there is no ability to return a response. This makes it
> unsuitable for some sort of protocol that relies on bidirectional
> communication.
> My solution: In addition to the existing HTTPSource interface, I've added a
> BidirectionalHTTPSource interface that is provided the servlet response as a
> parameter. I've made some changes in the HTTP source allow for both types to
> co-exist, and my changes shouldn't affect anyone who is already using the
> existing interface.
> Also includes minor documentation updates to reflect this.
> Review: https://reviews.apache.org/r/18555/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
