Mikhail Sosonkin created NIFI-4776:
--------------------------------------
Summary: Test suite behavioral differences
Key: NIFI-4776
URL: https://issues.apache.org/jira/browse/NIFI-4776
Project: Apache NiFi
Issue Type: Bug
Reporter: Mikhail Sosonkin
I think there might a difference in behavior for how processor attributes are
evaluated in the test suite vs real execution. I'm not entirely sure if it is
an expected/acceptable behavior. It has to do with the DATA_SIZE_VALIDATOR.
Mine was defined as follows:
public static final PropertyDescriptor MAX_ROW_SIZE = new PropertyDescriptor
.Builder().name(BigQueryAttributes.MAX_ROW_SIZE_ATTR)
.displayName("Max row size")
.description(BigQueryAttributes.MAX_ROW_SIZE_DESC)
.required(true)
.defaultValue("1 MB")
.addValidator(StandardValidators.DATA_SIZE_VALIDATOR)
.build();
Then I would use it like this in the onTrigger method:
final long max_row_size = context.getProperty(MAX_ROW_SIZE).asLong();
I used it this way based on the examples I've seen in the other processors. In
the runtime it seems to be working great and gives me the byte values. However,
in testing it would throw an exception because it would try to parse "1 MB"
(the default value) as an actual Long. Of course, if I just place a long value
(like 1024) it would not pass the validation function. So, I did a more
explicit "cast" using the asDataSize method:
final long max_row_size =
context.getProperty(MAX_ROW_SIZE).asDataSize(DataUnit.B).longValue();
This solved my problems and makes the code a bit more explicit which is nice.
The annoying part is that the StandardProcessorTestRunner does not keep the
stacktrace from the exceptions generated in onTrigger of the processor
(StandardProcessorTestRunner:199)
final Throwable thrown = future.get();
That is what caused confusion for me. I hadn't realized that the exception was
being thrown via my code. So, if anything the test suite needs to do a better
job at delivering stack traces for the exceptions to help with debugging.
Depending on what you decide, there might be two tasks here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
