[
https://issues.apache.org/jira/browse/NIFI-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092322#comment-15092322
]
Oleg Zhurakousky edited comment on NIFI-1378 at 1/11/16 5:29 PM:
-----------------------------------------------------------------
I'd suggest to reopen this JIRA, since personally I don't think I agree with
the fix. Here are the reasons.
1. Our Get/PutJMS in its current implementation are coupled to ActiveMQ and
rely on ActiveMqConnectionFactory and its SSl counterpart. This means that we
can only support ActoveMQ URIs, yet we have no control over their structure and
I am afraid that adding our own validation may result in invalidating a
perfectly valid URI (e.g., _failover:(tcp://foo.bar:18987. .
.)?initialReconnectDelay=100. . ._ ). *So, why not let ActiveMQ handle any
possible malformed URI errors leaving us to only deal with exception coming
from it and translating it to user if necessary?*
2. The actual issue was with the fact that the bulletin message displayed in UI
was not informative and that is due to the bug in _JmsFactory_ where we assume
that _scheme_ will alway be part of the URI while it is not a requirement for
the URI. By simply adding a null check for uri.getSchema() woudl allow code to
proceed resulting in user seeing this:
{code}
. . . .
Failed to connect to JMS Server due to javax.jms.JMSException: Could not create
Transport. Reason: java.io.IOException: Transport not scheme specified:
[localhost]
{code}
. . . which is informative enough to allow user to see it although we may clean
it up a bit.
was (Author: ozhurakousky):
I'd suggest to reopen this JIRA, since personally I don't think I agree with
the fix. Here are the reasons.
1. Our Get/PutJMS in its current implementation are coupled to ActiveMQ and
rely on ActiveMqConnectionFactory and its SSl counterpart. This means that we
can only support ActoveMQ URIs, yet we have no control over their structure and
I am afraid that adding our own validation may result in invalidating a
perfectly valid URI (e.g., _failover:(tcp://foo.bar:78987. .
.)?initialReconnectDelay=100. . ._ ). *So, why not let ActiveMQ handle any
possible malformed URI errors leaving us to only deal with exception coming
from it and translating it to user if necessary?*
2. The actual issue was with the fact that the bulletin message displayed in UI
was not informative and that is due to the bug in _JmsFactory_ where we assume
that _scheme_ will alway be part of the URI while it is not a requirement for
the URI. By simply adding a null check for uri.getSchema() woudl allow code to
proceed resulting in user seeing this:
{code}
. . . .
Failed to connect to JMS Server due to javax.jms.JMSException: Could not create
Transport. Reason: java.io.IOException: Transport not scheme specified:
[localhost]
{code}
. . . which is informative enough to allow user to see it although we may clean
it up a bit.
> GetJMSQueue throws NPE with invalid URL
> ---------------------------------------
>
> Key: NIFI-1378
> URL: https://issues.apache.org/jira/browse/NIFI-1378
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 0.4.1
> Reporter: Joseph Witt
> Assignee: Joseph Witt
> Fix For: 0.5.0
>
> Attachments:
> 0001-NIFI-1378-added-validator-to-ensure-the-JMS-URI-has-.patch
>
>
> GetJMSQueue throws an NPE. Easily reproduced even without an actual JMS
> broker setup. Use a URL of 'localhost' and some bogus topic.
> {quote}
> 2016-01-10 01:20:23,430 WARN [Timer-Driven Process Thread-3]
> o.a.n.c.t.ContinuallyRunProcessorTask Administratively Yielding
> GetJMSQueue[id=e1ce5a1b-818a-4b84-b913-7
> 16e9206c73e] due to uncaught Exception: java.lang.NullPointerException
> 2016-01-10 01:20:23,431 WARN [Timer-Driven Process Thread-3]
> o.a.n.c.t.ContinuallyRunProcessorTask
> java.lang.NullPointerException: null
> at
> org.apache.nifi.processors.standard.util.JmsFactory.createConnectionFactory(JmsFactory.java:366)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.util.JmsFactory.createConnection(JmsFactory.java:111)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.util.JmsFactory.createConnection(JmsFactory.java:104)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.util.JmsFactory.createQueueMessageConsumer(JmsFactory.java:239)
> ~[na:na]
> at
> org.apache.nifi.processors.standard.GetJMSQueue.onTrigger(GetJMSQueue.java:63)
> ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-1.1.1.0-12.jar:1.1.1.0-12]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146)
> ~[nifi-framework-core-1.1.1.0-12.jar:1.1.1.0-12]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139)
> [nifi-framework-core-1.1.1.0-12.jar:1.1.1.0-12]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
> [nifi-framework-core-1.1.1.0-12.jar:1.1.1.0-12]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
> [nifi-framework-core-1.1.1.0-12.jar:1.1.1.0-12]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
