What Hari proposed is very close to what I wrote. I didn¹t write a specific method to get the response on successful commit, but I like the idea, because I think it¹ll make the code more readable. In response to Hari¹s suggestion, I¹d just add the HttpRequest object as a parameter in the ³on commit² methods. It may be useful to get the encoding amongst other things. I understand your suggestion Jeremy, but I would prefer the response to come from the handler (BidirectionalHTTPSourceHandler) in an error case also and very likely the code will be based on sendError().
From: "Jeremy Karlson (JIRA)" <[email protected]> Reply-To: <[email protected]> Date: Friday, February 28, 2014 at 1:36 PM To: <[email protected]> Subject: [jira] [Commented] (FLUME-2333) HTTP source handler doesn't allow for responses [ https://issues.apache.org/jira/browse/FLUME-2333?page=com.atlassian.jira.plu gin.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.h tml#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)
