[
https://issues.apache.org/jira/browse/NIFI-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543485#comment-16543485
]
Michael Moser commented on NIFI-5196:
-------------------------------------
I have another scenario when this happens. If the framework throws an
exception from the ProcessSession commit() method, then that exception
propagates out of rendezvousWithJms() and the AbstractJMSProcessor
onTrigger(). Situations like an OutOfMemoryError or IOException: No space left
on device can cause this.
In this situation, I don't think we should close and reopen connections to the
JMS hub in each onTrigger. So I propose a solution like this:
{code:java}
@Override
public void onTrigger(ProcessContext context, ProcessSession session) throws
ProcessException {
T worker = workerPool.poll();
if (worker == null) {
worker = buildTargetResource(context);
}
try {
rendezvousWithJms(context, session, worker);
}
finally {
workerPool.offer(worker);
}
}
{code}
In the case where OOM or out of disk space occurs, the valid connection simply
remains open. In the case where the connection configuration is wrong, the NiFi
manager should be able to notice the problem and stop the processor, which will
call the @OnStopped method and close the bad connection.
How does this sound?
> AbstractJMSProcessor can leave connection hanging open
> ------------------------------------------------------
>
> Key: NIFI-5196
> URL: https://issues.apache.org/jira/browse/NIFI-5196
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.6.0
> Reporter: Nick Coleman
> Assignee: Sivaprasanna Sethuraman
> Priority: Major
> Labels: JMS
>
> ConsumeJMS and PublishJMS are based on AbstractJMSProcessor. They can cause
> a connection to the MQ Server to be opened and not be closed until the NiFi
> server is rebooted.
> This can create a problem for an MQ when the initial setup entered is wrong
> for an IBM MQ system that only allows one connection per user. Subsequent
> connections are blocked as the first remains open. Another potential problem
> even if the subsequent connection works is the original connection is still
> open and taking up resources.
> A simple change to the AbstractJMSProcessor would be in the onTrigger()
> function:
>
> {code:java}
> @Override
> public void onTrigger(ProcessContext context, ProcessSession session) throws
> ProcessException {
> T worker = workerPool.poll();
> if (worker == null) {
> worker = buildTargetResource(context);
> }
> boolean offered = false;
> try {
> rendezvousWithJms(context, session, worker);
> offered = workerPool.offer(worker);
> }
> finally {
> if (!offered) {
> worker.shutdown();
> }
> }
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
