[
https://issues.apache.org/jira/browse/NIFI-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065392#comment-16065392
]
Michael Hogue edited comment on NIFI-3193 at 6/27/17 8:04 PM:
--------------------------------------------------------------
[~bdeep] : A couple of things. In thinking about your feature request to go
ahead and declare a queue if it doesn't exist, that's only possible for NiFi to
do if you're not using exchanges (i.e. you're just using the default exchange).
The reason is that RabbitMQ maintains a mapping of <RoutingKey, Queue> which
the exchanges leverage to route messages to the appropriate queue. In that
case, NiFi would have no knowledge of which queue the message would be routed
to.
Per one of the RabbitMQ docs [1], in the case that the exchange provided is
empty, then the routing key is assumed to be the queue name. In that case, we
could declare it if it doesn't exist. The issue is that there are a number of
arguments in queue declaration that i feel would need to be explicit (See
Queues in [1]). Perhaps it'd be better if the queue declaration were left to
RabbitMQ admins? Or maybe just have sensible defaults? Thoughts?
> For example, when you declare a queue with the name of
> "search-indexing-online", the AMQP 0-9-1 broker will bind it to the default
> exchange using "search-indexing-online" as the routing key. Therefore, a
> message published to the default exchange with the routing key
> "search-indexing-online" will be routed to the queue
> "search-indexing-online". In other words, the default exchange makes it seem
> like it is possible to deliver messages directly to queues, even though that
> is not technically what is happening.
[1] https://www.rabbitmq.com/tutorials/amqp-concepts.html -- See 'Default
Exchange', 'Queues'
was (Author: m-hogue):
[~bdeep] : A couple of things. In thinking about your feature request to go
ahead and declare a queue if it doesn't exist, that's only possible for NiFi to
do if you're not using exchanges (i.e. you're just using the default exchange).
The reason is that RabbitMQ maintains a mapping of <RoutingKey, Queue> which
the exchanges leverage to route messages to the appropriate queue. In that
case, NiFi would have no knowledge of which queue the message would be routed
to.
Per one of the RabbitMQ docs [1], in the case that the exchange provided is
empty, then the routing key is assumed to be the queue name. In that case, we
could declare it if it doesn't exist. The issue is that there are a number of
arguments in queue declaration that i feel would need to be explicit (See
Queues in [1]). Perhaps it'd be better if the queue declaration were left to
RabbitMQ admins? Thoughts?
> For example, when you declare a queue with the name of
> "search-indexing-online", the AMQP 0-9-1 broker will bind it to the default
> exchange using "search-indexing-online" as the routing key. Therefore, a
> message published to the default exchange with the routing key
> "search-indexing-online" will be routed to the queue
> "search-indexing-online". In other words, the default exchange makes it seem
> like it is possible to deliver messages directly to queues, even though that
> is not technically what is happening.
[1] https://www.rabbitmq.com/tutorials/amqp-concepts.html -- See 'Default
Exchange', 'Queues'
> Update ConsumeAMQP and PublishAMQP to retrieve username from certificate
> common name
> ------------------------------------------------------------------------------------
>
> Key: NIFI-3193
> URL: https://issues.apache.org/jira/browse/NIFI-3193
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Affects Versions: 1.0.0, 1.1.0, 0.7.1
> Reporter: Brian
> Assignee: Michael Hogue
>
> At the moment the NiFi AMQP processors can establish a SSL connection to
> RabbitMQ but still user a user defined username and password to authenticate.
> When using certificates RabbitMQ allows you to use to COMMON_NAME from the
> certificate to authenticate instead of providing a username and password.
> Unfortunately the NiFi processors do not support this so I would like to
> request an update to the processors to enable this functionality.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
