https://issues.apache.org/jira/browse/NIFI-6885
On Tue, Nov 19, 2019 at 9:57 AM Joe Ferner <[email protected]> wrote: > I'm filing a JIRA for the logUnbuildableDestination logging bug and will > knock this out shortly. > > Looking deeper on your warning, it sounds like your Flow File has a > jms_destination attribute on it which is separate than then PublishJMS > processor Destination Name property. While the Destination Name is properly > configured and is being evaluated for EL/variables, the jms_destination > attribute value is separate and I assume it does not contain "queue" or > "topic" in the value and therefor cannot properly set the JMS Header > destination name property. Including jms_* attributes is not a required > functionality for the message to be published. Take a look at the flow file > attributes and decide if you want to keep the jms_destination attribute > (and update it to include "queue" in the path) or remove it. > > I'm fairly new to the team, so if anyone has more knowledge on this > processor, please correct me if I'm wrong. > > Joe > > On Mon, Nov 18, 2019 at 11:37 PM Joe Ferner <[email protected]> wrote: > >> A couple things I noticed... >> >> There is a small bug when calling logUnbuildableDestination. It should >> get passed entry.getValue() not entry.getKey(). This would give you the >> intended warning message where "destination_name" would actually be the >> destination name being evaluated. This would help you see if the variable >> was being properly evaluated in the flow file attribute. >> >> If this were in place, I think you'd see your first attempt with >> "activemq:${myid}" not having its variable evaluated because while the >> processor does attempt to support variables in the destination name >> attribute, this support doesn't appear to extend into where >> buildDestination is being called to set the JMS Destination JMS header >> property. In this case, the original flow file attributes are being >> generically iterated over and the evaluated destination name is not being >> used. >> >> This being said, the reason why your publisher is still working correctly >> is the setting of the JMS Destination JMS header property is not necessary >> for the message to be properly published. This is more of an informational >> property. The publisher is explicitly publishing to the destination name as >> specified, including handling variables as intended. >> >> As for why you are still getting this error when you attempt with >> "activemq:queue:${myid}". This I'm not sure. Even if the variable is not >> evaluated as expected, the presence of "queue" in the value should >> eliminate the warning. >> >> On Mon, Nov 18, 2019 at 3:53 PM Santiago Acosta < >> [email protected]> wrote: >> >>> Hi, >>> >>> I am trying to configure a PublishJMS processor to publish to a QUEUE >>> with >>> a variable name using Expression Language. I set the Destination Name to >>> "activemq:${myid}" which uses an attribute I added to the flowfile in a >>> previous step >>> >>> My ConsumeJMS processor works great which means that my configuration is >>> OK. (More on this later) >>> >>> When the flowfile arrives at the PublishJMS processor, the following >>> bulletin warning shows up: >>> >>> WARNING >>> PublishJMS[id=...] Failed to determine destination type from destination >>> name 'jms_destination'. The 'jms_destination' header will not be set >>> >>> The flowfile passes through as a success, the queue is being created on >>> my >>> ActiveMQ service and I can browse the message's contents in the queue. >>> Everything seems to be working regardless of the warning. >>> >>> I took a look inside >>> >>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/JMSPublisher.java >>> where the error message is being generated. The "private Destination >>> buildDestination(final String destinationName)" method (line 136) seems >>> to >>> be returning null. >>> >>> I changed the Destination Name to "activemq:queue:${myid}" which does >>> contain the word "queue" and should pass the condition "if >>> (destinationName. >>> toLowerCase().contains("queue"))" described on line 145. I thought the >>> type >>> was derived from Destination Type but there is an actual check on the >>> name. >>> >>> What boggles my mind is that the warning keeps showing up which means >>> that >>> I do not know how to diagnose from where I am at. >>> >>> Do you know if this is just a simple bug/oversight? Should I be worried >>> about this warning? >>> >>> Thank you for your time. >>> >>> -- >>> Best regards, >>> *Santiago Acosta Arreaza* >>> >>> Prisma building, 1st floor, Office 1.5 >>> Fotógrafo José Norberto Rguez. Díaz st., 2 >>> San Cristobal de La Laguna, SC de Tenerife >>> 38204, Spain >>> >>> >>> +34 922 31 56 05 >>> www.intermodaltelematics.com >>> >>
