You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Aljoscha Krettek (Jira)" <ji...@apache.org> on 2020/06/23 11:47:00 UTC

[jira] [Assigned] (FLINK-18359) Log failures in handler instead of ElasticsearchSinkBase

     [ https://issues.apache.org/jira/browse/FLINK-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aljoscha Krettek reassigned FLINK-18359:
----------------------------------------

    Assignee: rinkako

> Log failures in handler instead of ElasticsearchSinkBase
> --------------------------------------------------------
>
>                 Key: FLINK-18359
>                 URL: https://issues.apache.org/jira/browse/FLINK-18359
>             Project: Flink
>          Issue Type: Improvement
>          Components: Connectors / ElasticSearch
>            Reporter: rinkako
>            Assignee: rinkako
>            Priority: Major
>              Labels: pull-request-available, usability
>             Fix For: 1.12.0
>
>
> The story is: when a flink job for ingesting large number of records from data sources, processing and indexing with Elasticsearch sink failed, we may restart it from a specific data set which contains lots of data which already sink into ES.
> At this case, a `INSERT IGNORE` semantics is necessary, and we use `public IndexRequest create(boolean create)` with `true` args and ignore the 409 restStatusCode at a customized ActionRequestFailureHandler to make it work.
> But, the `BulkProcessorListener` always log a error event before it calls the `failureHandler` in its `afterBulk` method, and will produce tons of error log for document id conflict, which we already know and handle them in customized ActionRequestFailureHandler.
> Therefore, it seems that the error log action at the ActionRequestFailureHandler (either the default IgnoringFailureHandler or a custom handler) is more flexible ?
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)