Hi Joe,

Here is what I can see in the App Log:

2016-12-01 09:28:52,004 ERROR [Timer-Driven Process Thread-4]
testing.nifi.processor.hdfs.testingPutHDFS ""
org.apache.hadoop.fs.azure.AzureException:
java.util.NoSuchElementException: An error occurred while enumerating the
result, check the original exception for details.
at
org.apache.hadoop.fs.azure.AzureNativeFileSystemStore.retrieveMetadata(AzureNativeFileSystemStore.java:1930)
~[hadoop-azure-2.7.2.jar:na]
at
org.apache.hadoop.fs.azure.NativeAzureFileSystem.getFileStatus(NativeAzureFileSystem.java:1592)
~[hadoop-azure-2.7.2.jar:na]
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1424)
~[hadoop-common-2.7.2.jar:na]
at
testing.nifi.processor.hdfs.testingPutHDFS.onTrigger(testingPutHDFS.java:260)
~[testing.nifi.processor-1.0.0.nar-unpacked/:na]
at
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
[nifi-api-0.7.0.jar:0.7.0]
at
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
[nifi-framework-core-0.7.0.jar:0.7.0]
at
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
[nifi-framework-core-0.7.0.jar:0.7.0]
at
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
[nifi-framework-core-0.7.0.jar:0.7.0]
at
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
[nifi-framework-core-0.7.0.jar:0.7.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
[na:1.8.0_101]
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
[na:1.8.0_101]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
Source) [na:1.8.0_101]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
Source) [na:1.8.0_101]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
[na:1.8.0_101]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
[na:1.8.0_101]
at java.lang.Thread.run(Unknown Source) [na:1.8.0_101]
Caused by: java.util.NoSuchElementException: An error occurred while
enumerating the result, check the original exception for details.
at
com.microsoft.azure.storage.core.LazySegmentedIterator.hasNext(LazySegmentedIterator.java:113)
~[azure-storage-2.0.0.jar:na]
at
org.apache.hadoop.fs.azure.StorageInterfaceImpl$WrappingIterator.hasNext(StorageInterfaceImpl.java:128)
~[hadoop-azure-2.7.2.jar:na]
at
org.apache.hadoop.fs.azure.AzureNativeFileSystemStore.retrieveMetadata(AzureNativeFileSystemStore.java:1909)
~[hadoop-azure-2.7.2.jar:na]
... 15 common frames omitted
Caused by: com.microsoft.azure.storage.StorageException: Forbidden
at
com.microsoft.azure.storage.StorageException.translateFromHttpStatus(StorageException.java:202)
~[azure-storage-2.0.0.jar:na]
at
com.microsoft.azure.storage.StorageException.translateException(StorageException.java:172)
~[azure-storage-2.0.0.jar:na]
at
com.microsoft.azure.storage.core.ExecutionEngine.executeWithRetry(ExecutionEngine.java:273)
~[azure-storage-2.0.0.jar:na]
at
com.microsoft.azure.storage.core.LazySegmentedIterator.hasNext(LazySegmentedIterator.java:109)
~[azure-storage-2.0.0.jar:na]
... 17 common frames omitted
Caused by: java.lang.NullPointerException: null
at
com.microsoft.azure.storage.core.ExecutionEngine.executeWithRetry(ExecutionEngine.java:181)
~[azure-storage-2.0.0.jar:na]
... 18 common frames omitted

Regards,
Manish

On Thu, Dec 1, 2016 at 10:36 AM, Joe Witt <joe.w...@gmail.com> wrote:

> Manish
>
> Please produce and share the thread dump I mentioned.
>
> Thanks
> Joe
>
> On Dec 1, 2016 7:23 AM, "Manish G" <manish.gg...@gmail.com> wrote:
>
>> Hi,
>>
>> I don't know why, but this is happening now more frequently. Where should
>> I look into to find the root cause?
>>
>> Thanks,
>> Manish
>>
>> On Wed, Nov 30, 2016 at 9:20 PM, Manish G <manish.gg...@gmail.com> wrote:
>>
>>> Hi Joe,
>>>
>>> Thanks for the quick reply. Yes, the processor keeps running on a single
>>> thread (even after stopping). And the number remains there even after
>>> stopping.
>>> Today, it happened on my customized putHDFS processor. Only thing
>>> different in this processor is - I have added an additional attribute that
>>> tells if the processor created the directory while loading the file on
>>> HDFS. I don't think this should be the issue though.
>>>
>>> Regards,
>>> Manish
>>>
>>>
>>> On Wed, Nov 30, 2016 at 7:05 PM, Joe Witt <joe.w...@gmail.com> wrote:
>>>
>>>> Manish
>>>>
>>>> When it is stuck do you see a number in the top right corner of the
>>>> processor?  When you stop it does the number remain?  That number is
>>>> telling you how many threads are still executing.  Which processor are
>>>> we talking about?  When it is in the stuck state can you please run
>>>> bin/nifi.sh dump.  If you can then share the nifi-bootstrap.log that
>>>> would aid us in narrowing in on a possible cause.
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Wed, Nov 30, 2016 at 7:02 PM, Manish G <manish.gg...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > I have noticed that sometime a flow file gets stuck on a processor
>>>> for a
>>>> > very long time for no reason and then I can not even stop the
>>>> processor to
>>>> > look at the flow flow file from queue. If I click on stop, then
>>>> processor
>>>> > goes into a state where I cannot start/stop the processor.
>>>> >
>>>> > On restarting the NiFi, the file gets processed successfully and
>>>> routed to
>>>> > success queue. I checked in App log, but everything seems to be
>>>> normal for
>>>> > the flow file. I don't see anything mysterious in provenance too
>>>> (except
>>>> > that queue time is in hours).
>>>> >
>>>> > Has anyone else faced a similar issue? What else should I check to
>>>> identify
>>>> > the root cause for this?
>>>> >
>>>> > Thanks,
>>>> > Manish
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> *With Warm Regards,*
>>> *Manish*
>>>
>>
>>
>>
>> --
>>
>>
>> *With Warm Regards,*
>> *Manish*
>>
>


-- 


*With Warm Regards,*
*Manish*

Reply via email to