nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gaspar, Carson" <>
Subject RE: PutElasticsearchHttp error behaviour
Date Mon, 07 Nov 2016 18:09:05 GMT
It stays in the queue on a field type error, e.g.:
[2016-11-07 12:37:17,263][DEBUG][action.bulk              ] [Cybele] [estreamer_index_2016.11.07][0]
failed to execute bulk item (index) index {[estreamer_index_2016.11.07][estreamer_doc][AVg_3ZmnIxO_esWdRpuM],
MapperParsingException[failed to parse [applicationId]]; nested: NumberFormatException[For
input string: "4294967295"];
	at org.elasticsearch.index.mapper.FieldMapper.parse(
	at org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(
	at org.elasticsearch.index.mapper.DocumentParser.parseValue(
	at org.elasticsearch.index.mapper.DocumentParser.parseObject(
	at org.elasticsearch.index.mapper.DocumentParser.parseDocument(
	at org.elasticsearch.index.mapper.DocumentMapper.parse(
	at org.elasticsearch.index.shard.IndexShard.prepareCreate(
	at org.elasticsearch.index.shard.IndexShard.prepareCreateOnPrimary(
	at org.elasticsearch.action.index.TransportIndexAction.prepareIndexOperationOnPrimary(
	at org.elasticsearch.action.index.TransportIndexAction.executeIndexRequestOnPrimary(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardIndexOperation(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(
	at org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(
	at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(
	at org.elasticsearch.transport.TransportService$4.doRun(
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
Caused by: java.lang.NumberFormatException: For input string: "4294967295"
	at java.lang.NumberFormatException.forInputString(
	at java.lang.Integer.parseInt(
	at java.lang.Integer.parseInt(
	at org.elasticsearch.index.mapper.core.IntegerFieldMapper.innerParseCreateField(
	at org.elasticsearch.index.mapper.core.NumberFieldMapper.parseCreateField(
	at org.elasticsearch.index.mapper.FieldMapper.parse(
	... 22 more

-----Original Message-----
From: Koji Kawamura [] 
Sent: Monday, November 07, 2016 12:10 AM
Subject: Re: PutElasticsearchHttp error behaviour

Hello Gaspar,

I looked at the PutElasticsearchHttp code, it distinguishes following two types of error:

1. Error occurs when the processor tries to connect Elasticsearch, but it couldn't. E.g. the
specified Elasticsearch URL is not correct and is thrown.
When this happens, the processor throws ProcessException, and NiFi framework keeps the FlowFile
in the queue, so that it can be retried later.
This indicates that DataFlowManager(user) has to update the processor configuration to make
it work properly.

2. The processor successfully sends a request to Elasticsearch, but Elasticsearch returns
error response. This happens with operations such as updating with a document Id that doesn't
exist in the target index.
When this happens, the processor routes the incoming FlowFile which caused the error, to failure

I think the error you encountered the former type of error above (#1).
If the error was returned from Elasticsearch, it should be routed to failure relationship
as you suspected. Would you please let us know about the specific error you got? A StackTrace
would be helpful.

BTW, PutElasticsearchHttp also has REL_RETRY relationship, but it seems it's not used currently.


On Thu, Nov 3, 2016 at 5:47 AM, Gaspar, Carson <> wrote:
> When PutElasticsearchHttp gets an error from Elasticsearch, it 
> _appears_ to never dequeue the problem flow file and just try it over 
> and over again. It certainly doesn’t route the problem flow file to 
> the retry or failure queues. This seems wrong to me – am I missing something?
> Nifi is from the Hortonworks 
> nifi_2_0_0_0_579-
> RPM.
View raw message