nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Ferner <>
Subject Re: PublishJMS - Failed to determine destination type from destination name (v1.9.2)
Date Tue, 19 Nov 2019 14:57:01 GMT
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.


On Mon, Nov 18, 2019 at 11:37 PM Joe Ferner <> 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 <
>> 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:
>> 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
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message