[
https://issues.apache.org/jira/browse/NIFI-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326265#comment-16326265
]
Marco Gaido commented on NIFI-4776:
-----------------------------------
Hi [~nologic]! I can't find any processor which uses `asLong()` for a data
size. Might you please state exactly where this happens? Thanks.
> 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
> Priority: Major
>
> 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)
