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 15:03:40 GMT

On Tue, Nov 19, 2019 at 9:57 AM Joe Ferner <> 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 <> 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