New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIFI-3402: Added etag support to InvokeHTTP #2150
Conversation
Since there's not a clean way to unit test this, the way i tested was to change unit tests and observe that there were etag cache hits until
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor fixes to follow some of the established best practices for configurability. Other than that, looks like a solid commit to me.
* The maximum size, in bytes, that the ETag cache should grow if it is enabled. | ||
* The size here is chosen arbitrarily, as the documentation doesn't suggest a recommended value. | ||
*/ | ||
private static final int MAX_ETAG_CACHE_SIZE_BYTES = 1024 * 1024 * 10; // 10MiB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making this configurable with a property descriptor would be a good idea. I think two property descriptors, one for the numeric portion and the other for the unit would be very helpful to users.
@@ -669,6 +694,14 @@ public void onTrigger(ProcessContext context, ProcessSession session) throws Pro | |||
final int maxAttributeSize = context.getProperty(PROP_PUT_ATTRIBUTE_MAX_LENGTH).asInteger(); | |||
final ComponentLog logger = getLogger(); | |||
|
|||
// log ETag cache metrics | |||
final boolean eTagEnabled = context.getProperty(PROP_USE_ETAG).asBoolean(); | |||
if(eTagEnabled) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think && logger.isDebugEnabled()
should be added to this line to prevent the extra work being done since this is only for debugging.
public static final PropertyDescriptor PROP_USE_ETAG = new PropertyDescriptor.Builder() | ||
.name("use-etag") | ||
.displayName("Use HTTP ETag") | ||
.required(true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs a description("")
call to set a description statement on the property.
Thanks for the review, @MikeThomsen! I agree & I'll make all of these changes. |
@MikeThomsen : I've added your suggestions. Please let me know if you'd like any more changes. |
Looks good to me. The only change I'd recommend is do a squashed commit so your patch is just one commit. Not a core committer, but FWIW +1 |
* @return the directory in which the ETag cache should be written | ||
*/ | ||
private static File getETagCacheDir() { | ||
return Files.createTempDir(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this directory be deleted on @OnUnscheduled
annotation call? Or is this done automatically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it's currently written, this should be done automatically via OS-controlled temporary folder cleanup [1]. I elected to do this to 1) avoid manual cleanup and 2) avoid introducing something error prone. As this is only a cache, its durability isn't important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good way to go. It should be platform agnostic and work as a sane default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. I just thought that OS-controlled temporary folder was being cleaned at server reboot by default and a NiFi server is probably not supposed to be rebooted very often.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvillard31 Since there is a configured size limit on the field, it should stick to a reasonable size since there is a sane default of 10MB. If a user is foolish enough to set that to 10GB, not our problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MikeThomsen - true but one temporary folder is created each time the processor is started. We could assume that the processor is going to be stopped/started a lot. But I agree, this is a edge case. I'm fine with the current implementation. If I really want to be meticulous I could suggest to add this information in the property description :)
@pvillard31 @m-hogue Think we can close the loop on this one? |
Yes. +1, merging to master, thanks! |
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically master)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.