joewitt commented on a change in pull request #3676: NIFI-6597 Azure Event Hub
Version Update
URL: https://github.com/apache/nifi/pull/3676#discussion_r336011505
##########
File path:
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java
##########
@@ -312,11 +317,13 @@ public void onScheduled(final ProcessContext context)
throws ProcessException, U
receiverFetchTimeout = null;
}
- final String connectionString = new ConnectionStringBuilder(new
URI("amqps://"+namespace+serviceBusEndpoint), eventHubName, policyName,
policyKey).toString();
- setupReceiver(connectionString);
+ final int numThreads = context.getMaxConcurrentTasks();
+ executor = Executors.newScheduledThreadPool(numThreads);
Review comment:
That context for Azure Event Hubs is helpful. We still would generally not
want to hand off a thread pool to another library unless absolutely necessary.
As we have threads available we would want to offer them to do necessary 'Event
Hub interaction' and 'process received data actions' all under our control.
Based on your response though it sounds like the provided threadpool approach
is the API offered by event hubs at this point. OK.
@mysunnytime
1. Is the threadpool that is created being properly accounted for with the
lifecycle of the processor? If the processors is stopped is the thread pool
shut down?
2. The number of threads matching the number of tasks can match the number
of tasks but this i
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
