question Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi in Support Questions

Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

oka — Tue, 10 Mar 2026 15:20:17 GMT

During testing of the Enterprise Message Bridge implemented using Apache NiFi, it was identified that the Content-Type header becomes null when messages are routed from Message Broker A to Message Broker B.

The bridge is designed to enable message flow between the two brokers using Apache NiFi as the intermediary integration layer. However, while validating message headers at the destination broker, the Content-Type attribute is not being preserved and is received as null.

This behavior was observed during message inspection at the consumer side connected to Broker B.

May I know how to preserve message Content-Type attribute/properties ?

Using : ConsumeJMS and PublishJMS
Protocol: AMQP 1.0

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

DianaTorres — Wed, 11 Mar 2026 02:26:33 GMT

@oka Welcome to the Cloudera Community!

To help you get the best possible solution, I have tagged our NiFi experts @MattWho @mburgess who may be able to assist you further.

Please keep us updated on your post, and we hope you find a satisfactory solution to your query.

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

MattWho — Wed, 11 Mar 2026 12:39:41 GMT

@oka

Can you share more details about your Apache NiFi version and dataflow configuration?

Full Apache NiFi version
PublishJMS processor configuration
Sample FlowFile metadata/attributes of a FlowFile queued to the PublishJMS processor (exclude any sensitive values).
Which FlowFile contains the attribute string you expect to be sent to JMS endpoint

These details can be helpful in evaluating your setup and possible issue/solution.

Thank you,

Matt

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

oka — Fri, 24 Apr 2026 11:59:43 GMT

1) 2.2.0
2) However, I didn’t notice any content-type or content-encoding attributes in the FlowFile within consumeJMS.

JMSXDeliveryCount 1 filename 576fb206-3a78-4330-b85e-2c7215f57702 jms.messagetype TextMessage jms.source.destination q/mal/test/dev/test-abc jms_deliveryMode 2 jms_destination t/mal/test/dev/test-abc/v1/test jms_expiration 0 jms_messageId ID:AMQP_NO_PREFIX:a25814dd-3135-4733-8378-bd8348f4ebbb jms_priority 4 jms_redelivered false jms_timestamp 1777010201098 path ./ uuid 576fb206-3a78-4330-b85e-2c7215f56602

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

oka — Fri, 24 Apr 2026 12:06:30 GMT

I noticed that the Content-Type and Content-Encoding headers are missing after using ConsumeJMS. Is this expected behavior? Since I’m implementing a message bridge, I’d like to preserve and pass along the same Content-Type and Content-Encoding values to the target broker. How can I achieve this?

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

MattWho — Wed, 29 Apr 2026 18:54:36 GMT

@oka

I believe your issue is that "-" is not a valid character in the JMS specification.
https://stackoverflow.com/questions/30022453/how-to-set-content-type-header-for-jms-message

While the "-" is valid for AMQP messages.
There is a ConsumeAMQP processor but I see it only supports AMQP version 0.91

You don't have a issue connecting but just sound like these specific headers are ignored since they contain that invalid JMS character.

There is an existing Apache NiFi jira (https://issues.apache.org/jira/browse/NIFI-14670) for adding AMQP 1.0 support to the AMQP processors; however, it is open and unassigned.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

oka — Sat, 02 May 2026 05:19:05 GMT

I’m able to connect to the message broker and successfully consume messages. However, I’ve noticed that some information—specifically contentType and contentEncoding—is missing. From what I understand, these fields are often treated as “private” since the Qpid JMS client does not provide a public API to set them directly.

As I’m building an enterprise bridge using Apache Nifi, I want to preserve the original contentType and contentEncoding values when republishing the same message to another broker. May I know how to do it?

Re: Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

MattWho — Mon, 04 May 2026 12:41:39 GMT

@oka

Perhaps others in the community may hav additional suggestions here, but since the "-" is not a valid character in JMS, you would need to use a AMQP processor to support these headers. As mentioned before there is a https://issues.apache.org/jira/browse/NIFI-14670 jira for adding AMQP 1.0 support to ConsumeAMQP processor, but it is still open and unassigned. Now that jira points to using the Qpid JMS Client in ConsumeJMS and as you experienced it works but still has limitations. Those limitations impact these specific properties with the "-" in the name. I would suggest adding your experience with trying to use Qpid AMQP in the above jira and what impacts it has on the two headers you require to maybe push the Apache community to adding AMQP 1.0 support to the AMQP specific processors.

Additionally, there is this jira (https://issues.apache.org/jira/browse/QPID-4992), where an individual expressed some success preserving the content type header by using ActiveMQ JMS API instead of the Qpid AMQP JMS API. So you may want to give this jira a read and maybe try this for yourself.

Thank you,
Matt