[
https://issues.apache.org/jira/browse/CAMEL-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338647#comment-14338647
]
Mark Mindenhall edited comment on CAMEL-8409 at 2/26/15 5:59 PM:
-----------------------------------------------------------------
Hi Claus,
I think the whole point of CAMEL-8190 was that Camel was disallowing something
allowed by kafka. In this case, it's legal to pass null for both keys. I
can't think of a use case for wanting to do so, but it does allow more simple
routes when prototyping.
For example, the following route would work, but log the warning:
{code}
from("mqtt:bar?subscribeTopicName=test.mqtt.topic")
.to("kafka:localhost:9092?someKafkaOptions");
{code}
Whereas if we throw an exception the route would need to look more like this:
{code}
from("mqtt:bar?subscribeTopicName=test.mqtt.topic")
.process(exchange -> exchange.getIn().setHeader(KafkaConstants.PARTITION_KEY,
"someKey"))
.to("kafka:localhost:9092?someKafkaOptions");
{code}
was (Author: mmindenhall):
Hi Claus,
I think the whole point of CAMEL-8190 was that Camel was disallowing something
allowed by kafka. In this case, it's legal to pass null for both keys. I
can't think of a use case for wanting to do so, but it does allow more simple
routes when prototyping.
For example, the following route would work, but log the warning:
{code}
from("mqtt:bar?subscribeTopicName=test.mqtt.topic")
.to("kafka:localhost:9092?someKafkaOptions");
{code}
Whereas if we throw an exception the route would need to look more like this:
{code}
from("mqtt:bar?subscribeTopicName=test.mqtt.topic")
.process(exchange -> exchange.getIn().setHeader(KafkaConstants.PARTITION_KEY,
"someKey"))
.to("kafka:localhost:9092:someKafkaOptions");
{code}
> Kafka producer: when no message key specified, use partition key
> ----------------------------------------------------------------
>
> Key: CAMEL-8409
> URL: https://issues.apache.org/jira/browse/CAMEL-8409
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
> Affects Versions: 2.14.2, 2.15.0
> Reporter: Mark Mindenhall
> Assignee: Claus Ibsen
> Priority: Critical
> Fix For: 2.14.2, 2.15.0
>
> Attachments:
> 0001-CAMEL-8409-fix-for-breaking-change-introduced-by-CAM.patch
>
>
> CAMEL-8190 has introduced behavior that has the potential to break existing
> code (hence setting to Critical priority so this can be fixed prior to
> 2.14.2/2.15.0 releases). It broke my code (using 2.14.2-SNAPSHOT builds) in
> development and staging, and I didn't notice the problem until tonight.
> Prior to CAMEL-8190, the value of the {{KafkaConstants.PARTITION_KEY}} header
> was used for both the {{key}} and {{partitionKey}} of the kafka
> {{KeyedMessage}}. My downstream consumers depended on this for the correct
> {{key}} of the consumed message. CAMEL-8190, changed things so the {{key}}
> is set only via the {{KafkaConstants.KEY}} header, and since my code didn't
> set that header, the {{key}} started coming through as {{null}} to downstream
> consumers.
> I propose the following to fix this (will attach a patch shortly):
> # If both {{KEY}} _and_ {{PARTITION_KEY}} are specified, no change from
> CAMEL-8190
> # If just one is specified, call the {{KeyedMessage}} 3-argument constructor
> with the value (uses the value for both {{key}} and {{partitionKey}})
> # If neither are specified, pass {{null}} for both...but IMHO, a warning
> should be logged, as it seems unlikely that the user knowingly omitted both
> values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
