[jira] [Commented] (FLUME-2333) HTTP source handler doesn't allow for responses

["Hari Shreedharan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLUME-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916284#comment-13916284 ] 

Hari Shreedharan commented on FLUME-2333:
-----------------------------------------

I like the idea of this jira, but I am not entirely sure of having a custom handler. I'd prefer not move the transactional semantics out of the source - I don't want broken handlers causing data loss etc. Flexibility is good until custom code starts breaking guarantees.

One of the reasons I did not make the handler bidrectional was that there was no way to tell the handler that the channel writes may have failed, and so the last message which the handler may have sent to the client may have been incorrect. Even now, you'd have to call the handler a 2nd time saying that things failed and the handler must send out an "amendment" to the previous message - which is why the handler is limited currently.

One way around this would be to add a 2nd Servlet for bidirectional handlers, that:
- passes the input to the handler, and gets a list of events
- writes events to the channel
- successful commit: calls a success method in the handler (which gets the HttpResponse object as a parameter)
- failed commit: calls a failure method in the handler (also gets the HttpResponse object).
This ensures that the handler can send the correct message based on successful or failed commit.

Does that make sense?

> 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)