Skip to main content
oka
oka
Silver ⭐️⭐️
March 10, 2026
Question

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

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

7 replies

DianaTorres
Community Manager
DianaTorres
Community Manager
March 11, 2026

 @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.

Translate
Regards, Diana Torres, Senior Community Moderator
MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
March 11, 2026

@oka 

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

  1. Full Apache NiFi version
  2. PublishJMS processor configuration
  3. Sample FlowFile metadata/attributes of a FlowFile queued to the PublishJMS processor (exclude any sensitive values).
  4. 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

Translate
    oka
    okaAuthor
    Silver ⭐️⭐️
    April 24, 2026

    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

     

    Translate
    oka
    okaAuthor
    Silver ⭐️⭐️
    April 24, 2026

    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?

    Translate
    MattWho
    Titanium ⭐️⭐️⭐️
    MattWho
    Titanium ⭐️⭐️⭐️
    April 29, 2026

    @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

    Translate
    oka
    okaAuthor
    Silver ⭐️⭐️
    May 2, 2026

    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?

    Translate
    MattWho
    Titanium ⭐️⭐️⭐️
    MattWho
    Titanium ⭐️⭐️⭐️
    May 4, 2026

    @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. 

    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

     

    Translate
    Terms & ConditionsAccessibility statement