Hi Mark, Thanks for clarifying that self-looping connections will still be processed in back pressure situations.
For this specific case, we can probably live without the additional routing to the logging component and back. I think, however, that there are cases when such ping-pong routing in failure cases can be very useful. E.g. for alerting someone actively, publishing some information on a status page, ... etc. Therefore I feel it would be great if NiFi could be extended to avoid such back pressure deadlock situations. Maybe through some kind of automatic deadlock detection, or by marking certain incoming relations as not back pressure relevant (same as self-looping connections). Thanks, Arne > On 23. Oct 2017, at 15:00, Mark Payne <[email protected]> wrote: > > Hi Arne, > > Generally, the approach that is used in such a situation would be to route > failure back to the PublishJMS processor > itself (without diverting first to a LogAttribute processor). The PublishJMS > processors itself should be logging an error > with the FlowFile's identity. Then, troubleshooting can be done by inspecting > the queue (right-click, List Queue) or > via Data Provenance [1]. When a processor encounters backpressure, it still > will continue to process data that comes > in on self-looping connections. So the failure relationship would still get > processed. > > Does this help? > > Thanks > -Mark > > > > [1] http://nifi.apache.org/docs/nifi-docs/html/user-guide.html#data_provenance > > > >> On Oct 23, 2017, at 6:46 AM, Arne Degenring <[email protected]> >> wrote: >> >> Hi, >> >> We came across a situation when we experience a kind of “back pressure dead >> lock”. >> >> In our setup, this occurs around PublishJMS when the target JMS queue is >> full. Please find attached a screenshot of the relevant flow. >> >> The failure relation we route to a logging component, and then back to >> PublishJMS for retry. Sooner or later, the failure and retry queues will >> become full and produce backpressure towards the main input (which is good). >> The problem is that the same back pressure is also applied to the retry >> queue. >> >> In this situation, PublishJMS will not be called at all any longer. Even >> when the JMS problem resolves, the whole thing stays deadlocked. >> >> Is there a recommended way to avoid such situation? >> >> Obviously, an admin can temporarily increase the back pressure threshold of >> the failure connection, once the JMS problem is resolved. But it would be >> nicer if the problem could resolve automatically, i.e. PublishJMS should >> keep retrying somehow. >> >> Any hints? >> >> Thanks, >> Arne >> >> >> >> <backpressure-deadlock.png> >
