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