RE: Camel RabbitMQ sink connector plugin is not getting added in Kafka Connect
Hi Andrea,
Thanks a lot for the suggestion, it helped fix the issue, I can see the plugin.
Regards,
Gururaj
-Original Message-
From: Andrea Cosentino
Sent: dinsdag 15 maart 2022 10:18
To: users@camel.apache.org
Subject: Re: Camel RabbitMQ sink connector plugin is not getting added in Kafka
Connect
[You don't often get email from anco...@gmail.com. Learn why this is important
at http://aka.ms/LearnAboutSenderIdentification.]
You don't have to copy the jar, you need to explode the tar.gz provided:
https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-rabbitmq-kafka-connector/0.11.5/camel-rabbitmq-kafka-connector-0.11.5-package.tar.gz
Each of the connectors from camel-kafka-connector, needs to live in their own
directory in the plugin.path location.
So you should have a folder with all the needed bits coming from the tar.gz.
Only the jar won't work. This is also explained in the documentation:
https://camel.apache.org/camel-kafka-connector/0.11.x/user-guide/getting-started/try-it-out-locally.html
Il giorno mar 15 mar 2022 alle ore 10:11 Gururaj Maddodi <
gururaj.madd...@6gorillas.nl> ha scritto:
> Hi all,
>
> I'm trying a setup in which I need to push data from Kafka to RabbitMQ.
> I'm using Debezium Kafka Connect base image and adding additional
> plugins as required. As sink connector to RabbitMQ, I'm trying out
> Camel RabbitMQ connector plugin. I've copied the plugin jar in the
> plugin.path of Kafka Connect. I can see in the logs that Kafka Connect
> starts up, that it find the Camel plugin jar and registers the loader:
>
> 2022-03-14 14:39:13,303 INFO || Loading plugin from:
> /kafka/connect/camel-kafka-connectors
> [org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader]
> 2022-03-14 14:39:13,890 INFO || Registered loader:
> PluginClassLoader{pluginLocation=file:/kafka/connect/camel-kafka-conne
> ctors/}
> [org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader]
>
> But, it doesn't seem to add the plugin to the list of connectors.
> Subsequently, if I check the list of connectors using Kafka Conenct
> REST API, I cannot find Camel RabbitMQ plugin. If I try to add a
> connector using
> "org.apache.camel.kafkaconnector.rabbitmq.CamelRabbitmqSinkConnector",
> I get "Failed to find any class that implements Connector and which name
> matches org.apache.camel.kafkaconnector.rabbitmq.CamelRabbitmqSinkConnector"
>
> If anyone had previously encountered this issue or any suggestions,
> would be really helpful.
>
> Regards,
> Gururaj
>
>
>
Re: Camel RabbitMQ sink connector plugin is not getting added in Kafka Connect
You don't have to copy the jar, you need to explode the tar.gz provided:
https://repo.maven.apache.org/maven2/org/apache/camel/kafkaconnector/camel-rabbitmq-kafka-connector/0.11.5/camel-rabbitmq-kafka-connector-0.11.5-package.tar.gz
Each of the connectors from camel-kafka-connector, needs to live in their
own directory in the plugin.path location.
So you should have a folder with all the needed bits coming from the
tar.gz.
Only the jar won't work. This is also explained in the documentation:
https://camel.apache.org/camel-kafka-connector/0.11.x/user-guide/getting-started/try-it-out-locally.html
Il giorno mar 15 mar 2022 alle ore 10:11 Gururaj Maddodi <
gururaj.madd...@6gorillas.nl> ha scritto:
> Hi all,
>
> I'm trying a setup in which I need to push data from Kafka to RabbitMQ.
> I'm using Debezium Kafka Connect base image and adding additional plugins
> as required. As sink connector to RabbitMQ, I'm trying out Camel RabbitMQ
> connector plugin. I've copied the plugin jar in the plugin.path of Kafka
> Connect. I can see in the logs that Kafka Connect starts up, that it find
> the Camel plugin jar and registers the loader:
>
> 2022-03-14 14:39:13,303 INFO || Loading plugin from:
> /kafka/connect/camel-kafka-connectors
> [org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader]
> 2022-03-14 14:39:13,890 INFO || Registered loader:
> PluginClassLoader{pluginLocation=file:/kafka/connect/camel-kafka-connectors/}
> [org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader]
>
> But, it doesn't seem to add the plugin to the list of connectors.
> Subsequently, if I check the list of connectors using Kafka Conenct REST
> API, I cannot find Camel RabbitMQ plugin. If I try to add a connector using
> "org.apache.camel.kafkaconnector.rabbitmq.CamelRabbitmqSinkConnector", I
> get "Failed to find any class that implements Connector and which name
> matches org.apache.camel.kafkaconnector.rabbitmq.CamelRabbitmqSinkConnector"
>
> If anyone had previously encountered this issue or any suggestions, would
> be really helpful.
>
> Regards,
> Gururaj
>
>
>
RE: [camel-rabbitmq] - InOut pattern and temporary queues
I also expected the rabbitmq component to handle these IDs by itself. I'll give a closer look to message headers, there's something fishy going on. Thanks for you answer ! Regards, Guillaume. De : Claus Ibsen Envoyé : jeudi 10 juin 2021 06:56 À : users@camel.apache.org Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues On Wed, Jun 9, 2021 at 4:40 PM FERRY, Guillaume wrote: > > Hi folks, > > Here's a quick follow-up on my work with camel-rabbitmq. > So far, everything runs quite smoothly, but in some particular cases, some > messages being sent on a queue are not received on the other side. > > Here's the relevant log section : > > DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: > media_text_processing with CorrelationId: null > Yes I think this is a strong indicator that this is the problem, as if there is no correlation id, then then reply message cannot be "matched up" against the expected request message to known when its corresponding reply message was received and allow to continue to route. However I would also assume that the rabbitmq component (or rabbitmq client) would be able to auto generate an uuid as correlation id if you have not provided one specific. At least JMS can do that. > My question is simple : is it because CorrelationId is null ? > If that's, then I guess I'm having an intermediate processor that removes > this mandatory header. > > Thanks in advance ! > > Regards, > Guillaume. > > De : FERRY, Guillaume > Envoyé : mercredi 12 mai 2021 15:33 > À : users@camel.apache.org > Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues > > Hi Jean-Baptiste, > > Thanks for the details, I'll let you know if something goes wrong with > temporary queues, so far, it works like a charm. > > Best regards, > Guillaume. > ____ > De : Jean-Baptiste Onofre > Envoyé : mardi 11 mai 2021 17:59 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > Hi Guillaume, > > Yes, that’s probably the easiest way. > > To complete a little: > - the correlation can be done on the request message id using a temp > destination > - the correlation can be done on the client ID using physical destinations > > Most of the time, ReplyTo header contains a physical response destination, > where we correlate with the request message ID. > > Regards > JB > > > Le 11 mai 2021 à 15:42, FERRY, Guillaume a > > écrit : > > > > Hi Raymond, > > > > Thanks a lot for this crystal clear answer. > > I'll let Camel handle theses queues, then ! > > > > Best regards, > > Guillaume. > > > > De : ski n > > Envoyé : mardi 11 mai 2021 15:38 > > À : users@camel.apache.org > > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > > > When working with a Request-Reply pattern the reply message needs to send > > to a second reply queue. The InOut pattern mostly goes like this: > > > > 1) Producer send request with correlationid to a queue > > 2) Consumer receives the message and send a reply to the reply queue > > 3) Producer matches the reply message through the correlationid and > > consumes the reply. If there is no matching message a time out is thrown. > > > > There are two options for the Reply Queue: > > > > 1) Temporary queue. > > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > > header/parameter. > > > > Temporary queues are the default behavior. In general, it's easier to let > > the correlationid and temporary reply handled by Camel and the Broker. In > > some cases you need to fall back to fixed reply queues. > > > > Regards, > > > > Raymond > > > > > > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > > guillaume.fe...@bertin.fr>: > > > >> Hi everyone, > >> > >> I'm developing an application that relies mostly on Camel (3.9.0) and its > >> dedicated RabbitMQ / REST components. > >> My routes are specified in XML (with Spring beans). > >> > >> Here's a simple route : > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> The percolate_queue defined in another XML contains a single Camel > >> processor, which returns a basic JSON. &g
Re: [camel-rabbitmq] - InOut pattern and temporary queues
On Wed, Jun 9, 2021 at 4:40 PM FERRY, Guillaume wrote: > > Hi folks, > > Here's a quick follow-up on my work with camel-rabbitmq. > So far, everything runs quite smoothly, but in some particular cases, some > messages being sent on a queue are not received on the other side. > > Here's the relevant log section : > > DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: > media_text_processing with CorrelationId: null > Yes I think this is a strong indicator that this is the problem, as if there is no correlation id, then then reply message cannot be "matched up" against the expected request message to known when its corresponding reply message was received and allow to continue to route. However I would also assume that the rabbitmq component (or rabbitmq client) would be able to auto generate an uuid as correlation id if you have not provided one specific. At least JMS can do that. > My question is simple : is it because CorrelationId is null ? > If that's, then I guess I'm having an intermediate processor that removes > this mandatory header. > > Thanks in advance ! > > Regards, > Guillaume. > > De : FERRY, Guillaume > Envoyé : mercredi 12 mai 2021 15:33 > À : users@camel.apache.org > Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues > > Hi Jean-Baptiste, > > Thanks for the details, I'll let you know if something goes wrong with > temporary queues, so far, it works like a charm. > > Best regards, > Guillaume. > ________ > De : Jean-Baptiste Onofre > Envoyé : mardi 11 mai 2021 17:59 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > Hi Guillaume, > > Yes, that’s probably the easiest way. > > To complete a little: > - the correlation can be done on the request message id using a temp > destination > - the correlation can be done on the client ID using physical destinations > > Most of the time, ReplyTo header contains a physical response destination, > where we correlate with the request message ID. > > Regards > JB > > > Le 11 mai 2021 à 15:42, FERRY, Guillaume a > > écrit : > > > > Hi Raymond, > > > > Thanks a lot for this crystal clear answer. > > I'll let Camel handle theses queues, then ! > > > > Best regards, > > Guillaume. > > > > De : ski n > > Envoyé : mardi 11 mai 2021 15:38 > > À : users@camel.apache.org > > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > > > When working with a Request-Reply pattern the reply message needs to send > > to a second reply queue. The InOut pattern mostly goes like this: > > > > 1) Producer send request with correlationid to a queue > > 2) Consumer receives the message and send a reply to the reply queue > > 3) Producer matches the reply message through the correlationid and > > consumes the reply. If there is no matching message a time out is thrown. > > > > There are two options for the Reply Queue: > > > > 1) Temporary queue. > > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > > header/parameter. > > > > Temporary queues are the default behavior. In general, it's easier to let > > the correlationid and temporary reply handled by Camel and the Broker. In > > some cases you need to fall back to fixed reply queues. > > > > Regards, > > > > Raymond > > > > > > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > > guillaume.fe...@bertin.fr>: > > > >> Hi everyone, > >> > >> I'm developing an application that relies mostly on Camel (3.9.0) and its > >> dedicated RabbitMQ / REST components. > >> My routes are specified in XML (with Spring beans). > >> > >> Here's a simple route : > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> The percolate_queue defined in another XML contains a single Camel > >> processor, which returns a basic JSON. > >> > >> When I'm calling the REST endpoint : > >> > >> * A message is sent to percolate_queue without issues > >> * The Camel processor is invoked, and returns its value (which I get > >> as a response for my REST call) > >> > >> However, I noticed a temporary queue amq.gen.XXX has been created
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Hi folks, Here's a quick follow-up on my work with camel-rabbitmq. So far, everything runs quite smoothly, but in some particular cases, some messages being sent on a queue are not received on the other side. Here's the relevant log section : DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: media_text_processing with CorrelationId: null My question is simple : is it because CorrelationId is null ? If that's, then I guess I'm having an intermediate processor that removes this mandatory header. Thanks in advance ! Regards, Guillaume. De : FERRY, Guillaume Envoyé : mercredi 12 mai 2021 15:33 À : users@camel.apache.org Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues Hi Jean-Baptiste, Thanks for the details, I'll let you know if something goes wrong with temporary queues, so far, it works like a charm. Best regards, Guillaume. De : Jean-Baptiste Onofre Envoyé : mardi 11 mai 2021 17:59 À : users@camel.apache.org Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues Hi Guillaume, Yes, that’s probably the easiest way. To complete a little: - the correlation can be done on the request message id using a temp destination - the correlation can be done on the client ID using physical destinations Most of the time, ReplyTo header contains a physical response destination, where we correlate with the request message ID. Regards JB > Le 11 mai 2021 à 15:42, FERRY, Guillaume a écrit : > > Hi Raymond, > > Thanks a lot for this crystal clear answer. > I'll let Camel handle theses queues, then ! > > Best regards, > Guillaume. > > De : ski n > Envoyé : mardi 11 mai 2021 15:38 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > When working with a Request-Reply pattern the reply message needs to send > to a second reply queue. The InOut pattern mostly goes like this: > > 1) Producer send request with correlationid to a queue > 2) Consumer receives the message and send a reply to the reply queue > 3) Producer matches the reply message through the correlationid and > consumes the reply. If there is no matching message a time out is thrown. > > There are two options for the Reply Queue: > > 1) Temporary queue. > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > header/parameter. > > Temporary queues are the default behavior. In general, it's easier to let > the correlationid and temporary reply handled by Camel and the Broker. In > some cases you need to fall back to fixed reply queues. > > Regards, > > Raymond > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > guillaume.fe...@bertin.fr>: > >> Hi everyone, >> >> I'm developing an application that relies mostly on Camel (3.9.0) and its >> dedicated RabbitMQ / REST components. >> My routes are specified in XML (with Spring beans). >> >> Here's a simple route : >> >> >> >> >> >> >> >> >> >> >> The percolate_queue defined in another XML contains a single Camel >> processor, which returns a basic JSON. >> >> When I'm calling the REST endpoint : >> >> * A message is sent to percolate_queue without issues >> * The Camel processor is invoked, and returns its value (which I get >> as a response for my REST call) >> >> However, I noticed a temporary queue amq.gen.XXX has been created >> automatically, to handle the reply. >> Is it the standard behaviour ? >> >> Before using camel-rabbitmq, we were relying on camel-spring-amqp ( >> https://github.com/Bluelock/camel-spring-amqp), which is now obsolete >> (and triggered the switch to camel-rabbitmq). >> And with this component, we did not have any temporary queues for this >> kind of routes. >> >> May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? >> If so, how can I set/adjust it to point on the existing percolate_queue ? >> >> Thanks a lot for your answers. >> >> Best regards, >> Guillaume. >> >>
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Hi Jean-Baptiste, Thanks for the details, I'll let you know if something goes wrong with temporary queues, so far, it works like a charm. Best regards, Guillaume. De : Jean-Baptiste Onofre Envoyé : mardi 11 mai 2021 17:59 À : users@camel.apache.org Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues Hi Guillaume, Yes, that’s probably the easiest way. To complete a little: - the correlation can be done on the request message id using a temp destination - the correlation can be done on the client ID using physical destinations Most of the time, ReplyTo header contains a physical response destination, where we correlate with the request message ID. Regards JB > Le 11 mai 2021 à 15:42, FERRY, Guillaume a écrit : > > Hi Raymond, > > Thanks a lot for this crystal clear answer. > I'll let Camel handle theses queues, then ! > > Best regards, > Guillaume. > > De : ski n > Envoyé : mardi 11 mai 2021 15:38 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > When working with a Request-Reply pattern the reply message needs to send > to a second reply queue. The InOut pattern mostly goes like this: > > 1) Producer send request with correlationid to a queue > 2) Consumer receives the message and send a reply to the reply queue > 3) Producer matches the reply message through the correlationid and > consumes the reply. If there is no matching message a time out is thrown. > > There are two options for the Reply Queue: > > 1) Temporary queue. > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > header/parameter. > > Temporary queues are the default behavior. In general, it's easier to let > the correlationid and temporary reply handled by Camel and the Broker. In > some cases you need to fall back to fixed reply queues. > > Regards, > > Raymond > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > guillaume.fe...@bertin.fr>: > >> Hi everyone, >> >> I'm developing an application that relies mostly on Camel (3.9.0) and its >> dedicated RabbitMQ / REST components. >> My routes are specified in XML (with Spring beans). >> >> Here's a simple route : >> >> >> >> >> >> >> >> >> >> >> The percolate_queue defined in another XML contains a single Camel >> processor, which returns a basic JSON. >> >> When I'm calling the REST endpoint : >> >> * A message is sent to percolate_queue without issues >> * The Camel processor is invoked, and returns its value (which I get >> as a response for my REST call) >> >> However, I noticed a temporary queue amq.gen.XXX has been created >> automatically, to handle the reply. >> Is it the standard behaviour ? >> >> Before using camel-rabbitmq, we were relying on camel-spring-amqp ( >> https://github.com/Bluelock/camel-spring-amqp), which is now obsolete >> (and triggered the switch to camel-rabbitmq). >> And with this component, we did not have any temporary queues for this >> kind of routes. >> >> May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? >> If so, how can I set/adjust it to point on the existing percolate_queue ? >> >> Thanks a lot for your answers. >> >> Best regards, >> Guillaume. >> >>
Re: [camel-rabbitmq] - InOut pattern and temporary queues
Hi Guillaume, Yes, that’s probably the easiest way. To complete a little: - the correlation can be done on the request message id using a temp destination - the correlation can be done on the client ID using physical destinations Most of the time, ReplyTo header contains a physical response destination, where we correlate with the request message ID. Regards JB > Le 11 mai 2021 à 15:42, FERRY, Guillaume a écrit : > > Hi Raymond, > > Thanks a lot for this crystal clear answer. > I'll let Camel handle theses queues, then ! > > Best regards, > Guillaume. > > De : ski n > Envoyé : mardi 11 mai 2021 15:38 > À : users@camel.apache.org > Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues > > When working with a Request-Reply pattern the reply message needs to send > to a second reply queue. The InOut pattern mostly goes like this: > > 1) Producer send request with correlationid to a queue > 2) Consumer receives the message and send a reply to the reply queue > 3) Producer matches the reply message through the correlationid and > consumes the reply. If there is no matching message a time out is thrown. > > There are two options for the Reply Queue: > > 1) Temporary queue. > 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" > header/parameter. > > Temporary queues are the default behavior. In general, it's easier to let > the correlationid and temporary reply handled by Camel and the Broker. In > some cases you need to fall back to fixed reply queues. > > Regards, > > Raymond > > > > > Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < > guillaume.fe...@bertin.fr>: > >> Hi everyone, >> >> I'm developing an application that relies mostly on Camel (3.9.0) and its >> dedicated RabbitMQ / REST components. >> My routes are specified in XML (with Spring beans). >> >> Here's a simple route : >> >> >> >> >> >> >> >> >> >> >> The percolate_queue defined in another XML contains a single Camel >> processor, which returns a basic JSON. >> >> When I'm calling the REST endpoint : >> >> * A message is sent to percolate_queue without issues >> * The Camel processor is invoked, and returns its value (which I get >> as a response for my REST call) >> >> However, I noticed a temporary queue amq.gen.XXX has been created >> automatically, to handle the reply. >> Is it the standard behaviour ? >> >> Before using camel-rabbitmq, we were relying on camel-spring-amqp ( >> https://github.com/Bluelock/camel-spring-amqp), which is now obsolete >> (and triggered the switch to camel-rabbitmq). >> And with this component, we did not have any temporary queues for this >> kind of routes. >> >> May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? >> If so, how can I set/adjust it to point on the existing percolate_queue ? >> >> Thanks a lot for your answers. >> >> Best regards, >> Guillaume. >> >>
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Hi Raymond, Thanks a lot for this crystal clear answer. I'll let Camel handle theses queues, then ! Best regards, Guillaume. De : ski n Envoyé : mardi 11 mai 2021 15:38 À : users@camel.apache.org Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues When working with a Request-Reply pattern the reply message needs to send to a second reply queue. The InOut pattern mostly goes like this: 1) Producer send request with correlationid to a queue 2) Consumer receives the message and send a reply to the reply queue 3) Producer matches the reply message through the correlationid and consumes the reply. If there is no matching message a time out is thrown. There are two options for the Reply Queue: 1) Temporary queue. 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" header/parameter. Temporary queues are the default behavior. In general, it's easier to let the correlationid and temporary reply handled by Camel and the Broker. In some cases you need to fall back to fixed reply queues. Regards, Raymond Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < guillaume.fe...@bertin.fr>: > Hi everyone, > > I'm developing an application that relies mostly on Camel (3.9.0) and its > dedicated RabbitMQ / REST components. > My routes are specified in XML (with Spring beans). > > Here's a simple route : > > > > > > > > > > > The percolate_queue defined in another XML contains a single Camel > processor, which returns a basic JSON. > > When I'm calling the REST endpoint : > > * A message is sent to percolate_queue without issues > * The Camel processor is invoked, and returns its value (which I get > as a response for my REST call) > > However, I noticed a temporary queue amq.gen.XXX has been created > automatically, to handle the reply. > Is it the standard behaviour ? > > Before using camel-rabbitmq, we were relying on camel-spring-amqp ( > https://github.com/Bluelock/camel-spring-amqp), which is now obsolete > (and triggered the switch to camel-rabbitmq). > And with this component, we did not have any temporary queues for this > kind of routes. > > May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? > If so, how can I set/adjust it to point on the existing percolate_queue ? > > Thanks a lot for your answers. > > Best regards, > Guillaume. > >
Re: [camel-rabbitmq] - InOut pattern and temporary queues
When working with a Request-Reply pattern the reply message needs to send to a second reply queue. The InOut pattern mostly goes like this: 1) Producer send request with correlationid to a queue 2) Consumer receives the message and send a reply to the reply queue 3) Producer matches the reply message through the correlationid and consumes the reply. If there is no matching message a time out is thrown. There are two options for the Reply Queue: 1) Temporary queue. 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" header/parameter. Temporary queues are the default behavior. In general, it's easier to let the correlationid and temporary reply handled by Camel and the Broker. In some cases you need to fall back to fixed reply queues. Regards, Raymond Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < guillaume.fe...@bertin.fr>: > Hi everyone, > > I'm developing an application that relies mostly on Camel (3.9.0) and its > dedicated RabbitMQ / REST components. > My routes are specified in XML (with Spring beans). > > Here's a simple route : > > > > > > > > > > > The percolate_queue defined in another XML contains a single Camel > processor, which returns a basic JSON. > > When I'm calling the REST endpoint : > > * A message is sent to percolate_queue without issues > * The Camel processor is invoked, and returns its value (which I get > as a response for my REST call) > > However, I noticed a temporary queue amq.gen.XXX has been created > automatically, to handle the reply. > Is it the standard behaviour ? > > Before using camel-rabbitmq, we were relying on camel-spring-amqp ( > https://github.com/Bluelock/camel-spring-amqp), which is now obsolete > (and triggered the switch to camel-rabbitmq). > And with this component, we did not have any temporary queues for this > kind of routes. > > May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? > If so, how can I set/adjust it to point on the existing percolate_queue ? > > Thanks a lot for your answers. > > Best regards, > Guillaume. > >
Re: Camel + RabbitMQ + SSL
Hi Phil,
I presume that the camel-rabbitmq component is picking up and using this
ConnectionFactory:
...
So I would see if SSL needs to be configured there, and not on the Camel
endpoint. Try setting the "useSslProtocol" [1] property on the
ConnectionFactory itself? (i.e. set it as a property alongside host, port,
username, password, etc.)
[1]: https://www.rabbitmq.com/ssl.html#java-client-connecting
Hope this helps?
Tom
On Tue, 14 Apr 2020 at 21:55, Willemann, Phil
wrote:
> Hello:
>
> I am using Camel 2.24.3 and RabbitMQ 3.17.7. I have been able to
> successfully build a Camel program to ingest data from my input source and
> send the results to RabbitMQ. I am happy with the results. Now I am
> required to use SSL between my Camel program and RabbitMQ. Both my Camel
> program and RabbitMQ Server are on the same Windows 10 machine.
>
> 1. I have configured RabbitMQ to expect TLS connections at port 5671 and I
> am pretty sure this is working because the rabbitmq utilities are working
> and give me the diagnostics I expect.
> 2. What I am less sure of is the configuration of my Camel context file.
>
> I have added two beans to my context to enable me to work with SSL and
> RabbitMQ
>
>
>
> class="org.springframework.amqp.rabbit.connection.RabbitConnectionFactoryBea
> n">
>
>
>
> class="com.rabbitmq.client.ConnectionFactory">
>
> value="#{systemEnvironment['AMQP_BROKER_HOST']}" />
> value="#{systemEnvironment['AMQP_BROKER_PORT']}" />
>
> value="#{systemEnvironment['AMQP_BROKER_USERNAME']}"
> />
>
> value="#{systemEnvironment['AMQP_BROKER_PASSWORD']}"
> />
>
>
> I am pretty sure this is correct. I know the rabbitConnectionFactory is
> correct because it is what I use for the non-SSL version. Here is part of
> the route that I have my question:
>
>
> uri="rabbitmq:{{amqp.exchange.track}}?exchangeType=topic&autoDelete=true
>
> &durable=false&routingKey={{amqp.exchange.routingkey}}&sslProtoc
> ol=true&hostname=localhost" />
>
> I have only added two parameters to my non-SSL route - the sslProtocol and
> hostname.
>
> 1. I tried just sslProtocol by itself and the error output said I needed a
> hostname
> 2. I added the hostname and now the error output says: "Address is invalid
> on local machine, or port is not valid remote machine"
> 3. A google search has not yielded anything that I have found to fix the
> problem. I am still searching, however I thought posting here might be a
> good idea.
>
> Thanks
> Respectfully
> Phil Willemann
>
>
>
>
>
Re: Camel-RabbitMQ-STOMP
Hi Mahesh,
The error above is related to the initial creation of the Camel route, is
pretty weird though that it can't parse the options although you
correctly spelled them. Which version of Camel do you use?
Also, in regards camel stomp with RabbitMQ, I honestly have no idea if it
is going to work although I don't see why wouldn't work.
Regards,
Omar
On Fri, Nov 22, 2019 at 12:51 PM Mahesh wrote:
> Hi All,
> I am new to message brokers. I successfully completed a POC using Spring
> Reactor Netty Stomp client (Spring messaging framework) to connect to
> RabbitMQ on port 61613 (port dedicated for STOMP). That was just a POC. Now
> i have to build something concrete to be able to deploy in prod
> environments. I was googling Spring Messaging Vs Spring Integration and
> stumbled upon Apache Camel.
> My question is: Can Apache camel be used to connect to RabbitMQ on port
> 61613.
>
> I read camel documents:
> 1. RabbitMQ component page talks about port 5672 and that is AMQP
> 2. STOMP component page talks about ActiveMQ
>
> I did not see any examples or documentation regarding Camel in conjunction
> with RabbitMQ and STOMP.
>
> I went ahead and tried establishing STOMP connection with RabbitMQ as
> mentioned below:
>
>
> from("stomp:queue:controllerlistener?brokerURL=tcp://localhost:61613&login=guest&passcode=guest").to("stream:out");
>
> I am getting an exception:
>
> org.apache.camel.FailedToCreateRouteException: Failed to create route
> route1: Route(route1)[[From[stomp:queue:test?brokerURL=tcp://localho...
> because of Failed to resolve endpoint:
>
> stomp://queue:test?brokerURL=tcp%3A%2F%2Flocalhost%3A61613&login=guest&passcode=guest
> due to: Failed to resolve endpoint:
>
> stomp://queue:test?brokerURL=tcp%3A%2F%2Flocalhost%3A61613&login=guest&passcode=guest
> due to: There are 3 parameters that couldn't be set on the endpoint. Check
> the uri if the parameters are spelt correctly and that they are properties
> of the endpoint. Unknown parameters=[{brokerURL=tcp://localhost:61613,
> login=guest, passcode=guest}]
>
> What is the right way to establish STOMP connection with RabbitMQ?
>
> Thanks,
>
> Mahesh
>
RE: camel-rabbitmq sheduled route acks all messages when shutting down
And another update.
By doing it the brutal way I'm getting my header. But why?
.
when(body().regex(".*deliveryType:BASIC}")).to(outputEndpoint).to(outputBasickEndpoint)//.to(notificationRouterEndpoint)
...
private void process(Exchange exchange) {
logger.info("RabbitMQ Persistence header after archiving: " +
exchange.getIn().getHeader("rabbitmq.DELIVERY_MODE"));
..
exchange.getIn().setHeader("rabbitmq.DELIVERY_MODE", 2);
producerTemplate.send(notificationRouterEndpoint, exchange); //this
is not even a hack anymore
}
I'm a bit confused as to why the choice/when expressions would be stripping out
the rabbitmq headers. Or is it the chain of the three .to expressions, but I've
.to all over the place in the application and the headers seem ok there. Though
this is the only place with three chained together like that. I'm not finding
anything suspicious about that in the documentation either. Please tell me it's
something simple I'm missing here! I really would not like to resort to the
above "solution".
Camel version is 2.21.3
Thanks,
Valdis
P.S. Tried it with the header expression instead of the body expression and it
still wouldn't populate the header.
From: Valdis Andersons
Sent: 05 November 2019 21:54
To: users@camel.apache.org
Subject: RE: camel-rabbitmq sheduled route acks all messages when shutting down
CAUTION: This email originated from outside of VHI. Do not click links or open
attachments unless you know the content is safe.
Hi All,
Did a bit of digging and the issue appears to be coming from upstream on the
producer. Here is the route configuration for it:
from("direct:archive")
.log("Receiving ${body}")
.aggregate(header("aggregationkey"))
.aggregationStrategyRef(aggregationStrategy)
.aggregationRepositoryRef(repoName)
.completionSize(batchSize)
.completionTimeout(batchTimeout)
.log("Sending out ${body}")
.to(archiveProcessor)
.split(body())
.log("processing Split: ${body}")
.process(this::process)
.choice()
.when(body().regex(".*deliveryType:BASIC}")).setHeader("rabbitmq.DELIVERY_MODE",
simple("2")).to(outputEndpoint).to(outputBasickEndpoint).to(notificationRouterEndpoint)
.when(body().regex(".*deliveryType:PRIORITY}")).to(outputEndpoint).to(outputPriorityEndpoint).to(priorityNotificationRouterEndpoint)
.endChoice()
.end();
Issue stems from the "notificationRouterEndpoint" receiving a message that has
had the DELIVERY_MODE header stripped out somewhere along the way. The other
headers I'm setting on the exchange seem to be still there when I get the
message directly from the RabbitMQ console but the Delivery Mode property seems
to be gone. The above is my last attempt at forcing it to stick to the message
but to avail.
Oddly enough the header seems to be there after the split and before the
choice/when block:
private void process(Exchange exchange) {
logger.info("RabbitMQ Persistence header after archiving: " +
exchange.getIn().getHeader("rabbitmq.DELIVERY_MODE"));
}
Gives me this in the logs:
[2019-11-05 21:33:30,822 Camel (camel-1) thread #2 - AggregateTimeoutChecker]
INFO ie.vhi.cch.builders.BatchArchiveFeedbackRouteBuilder - RabbitMQ
Persistence header after archiving: 2
By the time it gets to the rabbit queue the value is null. This is the rabbit
queue config for notificationRouterEndpoint:
notificationRouterEndpoint:
rabbitmq://vm1/notificationExchange?connectionFactory=rabbitConnectionFactory&autoDelete=false&queue=notificationQueue&exchangeType=topic&autoAck=false&bridgeEndpoint=true&concurrentConsumers=3&threadPoolSize=3&exchangePattern=InOnly&channelPoolMaxSize=3
&addresses=vm1,vm2,vm3
The idea here is to send out notifications that something has been archived
(batching the archive items helps with the load on the Archive Service). The
splitting is there to facilitate individual notification processing for each
archived item (since they can go different ways and also fail in all sorts of
different ways).
Any help/advice/hint on the above would be greatly appreciated.
Thanks and Regards,
Valdis
From: Valdis Andersons
Sent: 05 November 2019 15:59
To: users@camel.apache.org<mailto:users@camel.apache.org>
Subject: camel-rabbitmq sheduled route acks all messages when shutting down
Hi All,
Not sure I understand the issue fully, but I have scheduled route with this
config (it's throttled as well):
CronScheduledRoutePolicy emailSchedulingPolicy = new CronScheduledRoutePolicy();
emailSchedulingPolicy.setRouteStartTime(emailNotificationsStartSchedule);
emailSchedulingPolicy.setRouteStopTime(emailNotificationsStopSchedule);
Processor exceptionLoggingProcessor = (exchange) ->
RE: camel-rabbitmq sheduled route acks all messages when shutting down
Hi All,
Did a bit of digging and the issue appears to be coming from upstream on the
producer. Here is the route configuration for it:
from("direct:archive")
.log("Receiving ${body}")
.aggregate(header("aggregationkey"))
.aggregationStrategyRef(aggregationStrategy)
.aggregationRepositoryRef(repoName)
.completionSize(batchSize)
.completionTimeout(batchTimeout)
.log("Sending out ${body}")
.to(archiveProcessor)
.split(body())
.log("processing Split: ${body}")
.process(this::process)
.choice()
.when(body().regex(".*deliveryType:BASIC}")).setHeader("rabbitmq.DELIVERY_MODE",
simple("2")).to(outputEndpoint).to(outputBasickEndpoint).to(notificationRouterEndpoint)
.when(body().regex(".*deliveryType:PRIORITY}")).to(outputEndpoint).to(outputPriorityEndpoint).to(priorityNotificationRouterEndpoint)
.endChoice()
.end();
Issue stems from the "notificationRouterEndpoint" receiving a message that has
had the DELIVERY_MODE header stripped out somewhere along the way. The other
headers I'm setting on the exchange seem to be still there when I get the
message directly from the RabbitMQ console but the Delivery Mode property seems
to be gone. The above is my last attempt at forcing it to stick to the message
but to avail.
Oddly enough the header seems to be there after the split and before the
choice/when block:
private void process(Exchange exchange) {
logger.info("RabbitMQ Persistence header after archiving: " +
exchange.getIn().getHeader("rabbitmq.DELIVERY_MODE"));
}
Gives me this in the logs:
[2019-11-05 21:33:30,822 Camel (camel-1) thread #2 - AggregateTimeoutChecker]
INFO ie.vhi.cch.builders.BatchArchiveFeedbackRouteBuilder - RabbitMQ
Persistence header after archiving: 2
By the time it gets to the rabbit queue the value is null. This is the rabbit
queue config for notificationRouterEndpoint:
notificationRouterEndpoint:
rabbitmq://vm1/notificationExchange?connectionFactory=rabbitConnectionFactory&autoDelete=false&queue=notificationQueue&exchangeType=topic&autoAck=false&bridgeEndpoint=true&concurrentConsumers=3&threadPoolSize=3&exchangePattern=InOnly&channelPoolMaxSize=3
&addresses=vm1,vm2,vm3
The idea here is to send out notifications that something has been archived
(batching the archive items helps with the load on the Archive Service). The
splitting is there to facilitate individual notification processing for each
archived item (since they can go different ways and also fail in all sorts of
different ways).
Any help/advice/hint on the above would be greatly appreciated.
Thanks and Regards,
Valdis
From: Valdis Andersons
Sent: 05 November 2019 15:59
To: users@camel.apache.org
Subject: camel-rabbitmq sheduled route acks all messages when shutting down
Hi All,
Not sure I understand the issue fully, but I have scheduled route with this
config (it's throttled as well):
CronScheduledRoutePolicy emailSchedulingPolicy = new CronScheduledRoutePolicy();
emailSchedulingPolicy.setRouteStartTime(emailNotificationsStartSchedule);
emailSchedulingPolicy.setRouteStopTime(emailNotificationsStopSchedule);
Processor exceptionLoggingProcessor = (exchange) ->
logger.error("EmailNotificationRoute Error handled in camel.",
exchange.getProperty(Exchange.EXCEPTION_CAUGHT));
setErrorHandlerBuilder(deadLetterChannel(deadLetterQueue)
.onExceptionOccurred(exceptionLoggingProcessor));
onException(Exception.class)
.logExhaustedMessageHistory(true)
.useOriginalMessage();
from(emailNotificationInputEndpoint)
.routeId(EMAIL_NOTIFICATIONS).routePolicy(emailSchedulingPolicy).autoStartup(autoStartup)
.filter(notificationFilterPredicate)
.throttle(maxEmailNotificationsThroughput)
.timePeriodMillis(timePeriodMillisForThrottle)
.process(emailNotificationProcessor)
.to(emailNotificationOutEndpoint)
.end();
The schedule is like this:
startSchedule: 0 0 10 ? * TUE-FRI,SUN *
stopSchedule: 0 0 15 ? * TUE-FRI,SUN *
So at 3pm the thing did shut down as expected but there was an error thrown in
the logs (only thing I can see going wrong in the logs):
2019-11-05 15:00:11,358 [Camel (camel-1) thread #163 - ShutdownTask] ERROR
o.a.c.c.r.RabbitConsumer - Thread Interrupted!
The consumer config is this:
rabbitmq://vm1/emailnotificationExchange?connectionFactory=rabbitConnectionFactory&autoDelete=false&queue=emailnotificationQueue&exchangeType=topic&autoAck=false&bridgeEndpoint=true&concurrentConsumers=9&threadPoolSize=9&channelPoolMaxSize=9&prefetchCount=1&prefetchEnabled=true&requestTimeout=9&addresses=vm1,vm2,vm3
It's a clustered environment with the vm3 being a federated node. When the
route shut down this happened:
[cid:image001.png@01D59421.B32A1990]
All of the 2k+ messages got somehow ack'd even though I have autoAck=false and
this doesn't happen on a normal shutdown of the application. Am I missing
something here, anyone would be able to explain why that could b
RE: camel-rabbitmq automated recovery
Hi Claus,
Thanks for the response, had forgotten about this email completely. In the
meantime manged to figure out a working configuration - it's just leaving all
the recovery settings as default. Adding the URL parameters
"automaticRecoveryEnabled=true&networkRecoveryInterval=15000" just screws
things up as outlined below. With just the recovery enabled on the connection
factory (it's on by default) it works correctly.
I should have probably tested the clustering before adding any new URL
properties (like a baseline test), that would have revealed that recovery is on
and working by default. Live and learn I guess. Maybe a note could be added to
the documentation stating that those parameters are not needed on later
versions of Camel?
Thanks,
Valdis
-Original Message-
From: Claus Ibsen [mailto:claus.ib...@gmail.com]
Sent: 03 January 2019 12:18
To: users@camel.apache.org
Subject: Re: camel-rabbitmq automated recovery
Hi
Have you been able to try with a newer release such as Camel 2.23.0, as the
camel-rabbitmq component etc may been improved / bug fixed since that version
you are using.
On Mon, Nov 12, 2018 at 5:34 PM Valdis Andersons
wrote:
>
> Hi All,
>
>
>
> Hoping someone with more experience with RabbitMQ and Camel might be able to
> tell me what’s going on with the below scenario as I’m not sure I understand
> it right.
>
>
>
> We have now 3 servers in a test environment with RabbitMQ installed (v3.6.12,
> Elang 20.1), we’re using camel-rabbitmq component (2.21.3) in our Camel
> application to talk to the rabbit servers. Two of the servers (vm1 and vm2)
> are in a cluster and have mirrored queues, the third server (vm3) is not in
> the cluster but has federated queues and sits in a different data centre.
> What we’re trying to figure out now is how to do disaster recovery flip-over
> and it’s not working out too well so far.
>
>
>
> Here is an example of one of the consumer endpoints we have:
>
>
>
> rabbitmq://vm1:5671/someExchange?connectionFactory=rabbitConnectionFac
> tory&autoDelete=false&queue=someQueue&exchangeType=topic&autoAck=false
> &bridgeEndpoint=true&concurrentConsumers=10&threadPoolSize=10&channelP
> oolMaxSize=10&prefetchCount=1&prefetchEnabled=true&exchangePattern=InO
> nly&automaticRecoveryEnabled=true&networkRecoveryInterval=15000&addres
> ses=vm1:5671,vm2:5671,vm3:5671
>
>
>
> Here is the connection factory (sslEnabled property is set to true):
>
>
>
> public ConnectionFactory rabbitConnectionFactory() throws
> KeyManagementException, NoSuchAlgorithmException {
>
> ConnectionFactory cf = new ConnectionFactory();
>
> cf.setHost(rabbitHost);
>
> cf.setPort(rabbitPort);
>
> cf.setUsername(rabbitUser);
>
> cf.setPassword(rabbitPassword);
>
> cf.setVirtualHost(rabbitVirtualhost);
>
> if (sslEnabled)
>
> cf.useSslProtocol();
>
> return cf;
>
> }
>
>
>
> With only vm1 or vm2 going down it seems to work out just fine, the broker
> seems to take care of the mirroring and the client side (Camel) rarely
> notices a thing. Issues start when both of the cluster nodes (vm1 and vm2) go
> down, for some reason the third address in the list isn’t being tried for the
> recovery attempts. Without a Camel restart I’ve never seen the consumers
> flipping over to vm3.
>
>
>
> In the logs I’m getting the following, which is most likely as expected:
>
>
>
> 2018-11-12 10:55:10,161 [Camel (camel-1) thread #13 -
> RabbitMQConsumer] INFO o.a.c.c.r.RabbitConsumer - Received shutdown
> signal on the rabbitMQ channel
>
> 2018-11-12 10:55:10,161 [Camel (camel-1) thread #13 -
> RabbitMQConsumer] INFO o.a.c.c.r.RabbitConsumer - Attempting to open
> a new rabbitMQ channel
>
> 2018-11-12 10:55:10,161 [AMQP Connection 10.1.1.1:5671] ERROR
> c.r.c.i.ForgivingExceptionHandler - An unexpected connection driver
> error occured
>
> javax.net.ssl.SSLException: Connection has been shutdown:
> javax.net.ssl.SSLException: java.net.SocketException: Connection reset
> by peer: socket write error
>
> at sun.security.ssl.SSLSocketImpl.checkEOF(Unknown
> Source)
>
> at sun.security.ssl.AppInputStream.read(Unknown
> Source)
>
> at java.io.BufferedInputStream.fill(Unknown Source)
>
> at java.io.BufferedInputStream.read(Unknown Source)
>
> at java.io.DataInputStream.readUnsignedByte(Unknown
> Source)
>
> at
> com.rabbitmq.client.impl.Frame.readFrom(Frame.java:91)
>
>
Re: camel-rabbitmq automated recovery
Hi
Have you been able to try with a newer release such as Camel 2.23.0,
as the camel-rabbitmq component etc may been improved / bug fixed
since that version you are using.
On Mon, Nov 12, 2018 at 5:34 PM Valdis Andersons
wrote:
>
> Hi All,
>
>
>
> Hoping someone with more experience with RabbitMQ and Camel might be able to
> tell me what’s going on with the below scenario as I’m not sure I understand
> it right.
>
>
>
> We have now 3 servers in a test environment with RabbitMQ installed (v3.6.12,
> Elang 20.1), we’re using camel-rabbitmq component (2.21.3) in our Camel
> application to talk to the rabbit servers. Two of the servers (vm1 and vm2)
> are in a cluster and have mirrored queues, the third server (vm3) is not in
> the cluster but has federated queues and sits in a different data centre.
> What we’re trying to figure out now is how to do disaster recovery flip-over
> and it’s not working out too well so far.
>
>
>
> Here is an example of one of the consumer endpoints we have:
>
>
>
> rabbitmq://vm1:5671/someExchange?connectionFactory=rabbitConnectionFactory&autoDelete=false&queue=someQueue&exchangeType=topic&autoAck=false&bridgeEndpoint=true&concurrentConsumers=10&threadPoolSize=10&channelPoolMaxSize=10&prefetchCount=1&prefetchEnabled=true&exchangePattern=InOnly&automaticRecoveryEnabled=true&networkRecoveryInterval=15000&addresses=vm1:5671,vm2:5671,vm3:5671
>
>
>
> Here is the connection factory (sslEnabled property is set to true):
>
>
>
> public ConnectionFactory rabbitConnectionFactory() throws
> KeyManagementException, NoSuchAlgorithmException {
>
> ConnectionFactory cf = new ConnectionFactory();
>
> cf.setHost(rabbitHost);
>
> cf.setPort(rabbitPort);
>
> cf.setUsername(rabbitUser);
>
> cf.setPassword(rabbitPassword);
>
> cf.setVirtualHost(rabbitVirtualhost);
>
> if (sslEnabled)
>
> cf.useSslProtocol();
>
> return cf;
>
> }
>
>
>
> With only vm1 or vm2 going down it seems to work out just fine, the broker
> seems to take care of the mirroring and the client side (Camel) rarely
> notices a thing. Issues start when both of the cluster nodes (vm1 and vm2) go
> down, for some reason the third address in the list isn’t being tried for the
> recovery attempts. Without a Camel restart I’ve never seen the consumers
> flipping over to vm3.
>
>
>
> In the logs I’m getting the following, which is most likely as expected:
>
>
>
> 2018-11-12 10:55:10,161 [Camel (camel-1) thread #13 - RabbitMQConsumer] INFO
> o.a.c.c.r.RabbitConsumer - Received shutdown signal on the rabbitMQ channel
>
> 2018-11-12 10:55:10,161 [Camel (camel-1) thread #13 - RabbitMQConsumer] INFO
> o.a.c.c.r.RabbitConsumer - Attempting to open a new rabbitMQ channel
>
> 2018-11-12 10:55:10,161 [AMQP Connection 10.1.1.1:5671] ERROR
> c.r.c.i.ForgivingExceptionHandler - An unexpected connection driver error
> occured
>
> javax.net.ssl.SSLException: Connection has been shutdown:
> javax.net.ssl.SSLException: java.net.SocketException: Connection reset by
> peer: socket write error
>
> at sun.security.ssl.SSLSocketImpl.checkEOF(Unknown Source)
>
> at sun.security.ssl.AppInputStream.read(Unknown Source)
>
> at java.io.BufferedInputStream.fill(Unknown Source)
>
> at java.io.BufferedInputStream.read(Unknown Source)
>
> at java.io.DataInputStream.readUnsignedByte(Unknown Source)
>
> at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:91)
>
> at
> com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:164)
>
> at
> com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:596)
>
> at java.lang.Thread.run(Unknown Source)
>
> Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection
> reset by peer: socket write error
>
> at sun.security.ssl.Alerts.getSSLException(Unknown Source)
>
> at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
>
> at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
>
> at sun.security.ssl.SSLSocketImpl.handleException(Unknown
> Source)
>
> at sun.security.ssl.SSLSocketImpl.handleException(Unknown
> Source)
>
> at sun.security.ssl.AppOutputStream.write(Unknown Source)
>
> at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
>
> at java.io.BufferedOutputStream.flush(Unknown Source)
>
> at java.io.DataOutputStream.flush(Unknown Source)
>
> at
> com.rabbitmq.client.impl.SocketFrameHandler.flush(SocketFrameHandler.java:177)
>
> at
> com.rabbitmq.client.impl.AMQConnection.flush(AMQConnection.java:571)
>
> at
> com.rabbitmq.client.impl.AMQCommand.transmit(AMQCommand.java:134)
>
> at
> com.rabbitm
RE: camel-rabbitmq clustering failover issue
Never mind, we figured it out. Turns out mirroring is configured on the broker
side since RabbitMQ 3.0 (:facepalm).
Once the primary went down Camel couldn't do anything with the in-flight
messages anymore since the queues were not mirrored on the secondary vm. So the
below is probably a very expected outcome of that.
Thanks and apologies for this,
Valdis
From: Valdis Andersons
Sent: 24 September 2018 15:16
To: users@camel.apache.org
Subject: camel-rabbitmq clustering failover issue
Hi All,
Hopefully someone can help me out here. In the project I'm working on we're
using the camel-rabbitmq component to connect to a cluster of three RabbitMQ
nodes. We're using the addresses parameter in the URL configuration of the
RabbitMQ facing endpoints, like this:
from:rabbitmq://vmsys:5671/emailExchange?connectionFactory=rabbitConnectionFactory&autoDelete=false&queue=emailrouteQueue&exchangeType=topic&autoAck=false&addresses=vmsys:5671,vmsys2:5671,vmsys3:5671
Today the primary node 'vmsys' in that cluster got brought down for some OS
patches and Camel in turn started logging this:
WARN o.a.c.c.r.RabbitConsumer - Unable to obtain a RabbitMQ channel. Will try
again
INFO o.a.c.c.r.RabbitConsumer - Attempting to open a new rabbitMQ channel
Tried a restart of the application in the hopes that Camel might pick up the
next node 'vmsys2' in the addresses list but no such thing, instead this was
printed in the logs:
com.rabbitmq.client.ShutdownSignalException: channel error; protocol method:
#method(reply-code=404, reply-text=NOT_FOUND - home node
'rabbit@vmsys' of durable queue 'emailrouteQueue' in vhost '/comms' is down or
inaccessible, class-id=50, method-id=10)
In the RabbitMQ console on vmsys2 the queue statuses were showing up with a red
flag and a message stating 'The queue is located on a cluster node or nodes
that are down'.
I would have expected that Camel would simply switch over to the second node in
the addresses list if the primary goes down. Also, while I'm seeing the queues
from the vmsys2 node's console application it doesn't look like they're
actually being replicated there like for our Spring application queues.
Is there something wrong in endpoint configuration that you can see or the
connection factory setup? Think I followed the docs as best as I could.
Here is also how the rabbitConnectionFactory is instantiated:
@Bean(name = "rabbitConnectionFactory")
public ConnectionFactory customerCommsCachingConnectionFactory() throws
KeyManagementException, NoSuchAlgorithmException {
ConnectionFactory cf = new ConnectionFactory();
cf.setHost(rabbitHost);
cf.setPort(rabbitPort);
cf.setUsername(rabbitUser);
cf.setPassword(rabbitPassword);
cf.setVirtualHost(rabbitVirtualhost);
cf.setAutomaticRecoveryEnabled(false);
if (sslEnabled)
cf.useSslProtocol();
return cf;
}
Any help on this would be greatly appreciated. If you need any more info on
this please let me know, I'll do my best to supply it.
Thanks and Regards,
Valdis
Re: Camel RabbitMQ
Ok I figured out what the issue is. You must explicitly set the exchangepattern to InOut otherwise the replyto headers and queues are not created by default. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-RabbitMQ-tp5781455p5781457.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq only receive one message when autoAck is false
anybody can help? Thanks, Jeffrey -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-only-receive-one-message-when-autoAck-is-false-tp5758034p5758121.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq logging exceptions as debug
opened https://issues.apache.org/jira/browse/CAMEL-7967 thanks -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-logging-exceptions-as-debug-tp5757936p5758069.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq logging exceptions as debug
Hi Yeah that sounds like we should improve this. Feel free to log a JIRA ticket http://camel.apache.org/support On Thu, Oct 23, 2014 at 11:08 AM, Marco Crivellaro wrote: > Hi, > I am using Camel 2.14.0 > Connecting to RabbitMQ using camel-rabbitmq I've noticed that no ERROR is > logged if the component cannot connect, the exceptions are handled and > logged as DEBUG. > This is a bit inconvenient as logging all DEBUG messages for the component > fills up our logs, in production we usually set INFO as threshold. > > Is there any way of changing the logging level or be notified if the > component cannot connect? > > ActiveMQ component does not have this issue (at least on Camel 2.8.x which > we are using in production). > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-rabbitmq-logging-exceptions-as-debug-tp5757936.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: Camel RabbitMQ acknowledges event though autoAck is set to false and there is an exception in the route
Thanks Claus Ibsen for looking into this. Let me know when this fix will be available. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-RabbitMQ-acknowledges-event-though-autoAck-is-set-to-false-and-there-is-an-exception-in-the-roe-tp5756207p5756229.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel RabbitMQ acknowledges event though autoAck is set to false and there is an exception in the route
Hi
Yeah you are right I am fixing this now.
On Mon, Sep 8, 2014 at 8:35 PM, blr_developer wrote:
> Camel RabbitMQ component acknowledges the message even though the autoAck is
> set to false and there is an exception in the route. I don't know if I am
> doing anything wrong.
>
> My guess is that the error could be in the RabbitMQConsumer class.
>
> try {
> consumer.getProcessor().process(exchange);
>
> long deliveryTag = envelope.getDeliveryTag();
> if (!consumer.endpoint.isAutoAck()) {
> log.trace("Acknowledging receipt [delivery_tag={}]",
> deliveryTag);
> channel.basicAck(deliveryTag, false);
> }
>
> } catch (Exception e) {
> getExceptionHandler().handleException("Error processing
> exchange", exchange, e);
> }
>
> Process method does not throw exception but sets exception property of the
> exchange to the exception object when there is any error while processing
> the exchange. There may need to be a check to see if the exception property
> is null before acknowledging the message.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-RabbitMQ-acknowledges-event-though-autoAck-is-set-to-false-and-there-is-an-exception-in-the-roe-tp5756207.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: Camel RabbitMQ acknowledge messages
Hi,
If you set the option of autoAck is false, Camel will send the acknowledgement
to RabbitMQ when the exchange is processed.
If you want to do it in the batch mode, you may need to change the
RabbitMQConsumer, but I’m not sure how can get the channel if you want to send
the acknowledgement in your custom bean.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 17, 2014 at 9:31:03 PM, Reichert, Andre (andre.reich...@here.com)
wrote:
> Hi,
>
> We are using RabbitMQ for messaging huge amount of data. For good performance
> multi acknowledgment
> of messages is used. Further we send messages from RabbitMQ via EventManager
> for processing.
> After a batch we store results in data base and acknowledge processed
> messages.
>
> We would like to use Camel for connection to RabbitMQ but the acknowledgment
> of messages
> is hard coded in RabbitMQConsumer. This class has the implementation of
> com.rabbitmq.client.DefaultConsumer.handleDelivery
> that does acknowledgment of a message right after calling process method. See
> code snippet
> below. Is it possible to have the acknowledgment attached to the Exchange
> object or have
> another possibility to acknowledge messages except auto acknowledgement?
>
> Kind regards
> Andre Reichert
>
> Code snippet from org.apache.camel.component.rabbitmq.RabbitMQConsumer
>
> 123 consumer.getProcessor().process(exchange);
> 124
> 125 long deliveryTag = envelope.getDeliveryTag();
> 126 if (!consumer.endpoint.isAutoAck()) {
> 127 log.trace("Acknowledging receipt [delivery_tag={}]", deliveryTag);
> 128 channel.basicAck(deliveryTag, false);
> 129 }
>
>
>
>
> Andre Reichert
> Senior Engineer
> Map Community Platform
> Phone: +49 6196 589 337
>
>
> 50° 9' 43" N. 8° 32' 1" E
> HERE, a Nokia business
>
> Place of Business: HERE Germany GmbH & Co. KG, Am Kronberger Hang 8, 65824
> Schwalbach,
> Germany - Commercial Register: Amtsgericht Frankfurt am Main, HRA 43654;
> USt-ID-No.:
> DE 259 126 202; Managing Directors: Hans P.J. Gieszen, Robertus A.J. Houben
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that is
> privileged or
> confidential, and is intended for use only by the individual or entity to
> which it is addressed.
> Any disclosure, copying or distribution of the information by anyone else is
> strictly
> prohibited. If you have received this document in error, please notify us
> promptly by
> responding to this e-mail. Thank you.
>
>
Re: camel-rabbitmq
Thank you Willem. After upgrading to 2.13.0 and adding BridgeEndpoint=true to the URI solved this issue. I ended up using "addresses" as we have 2 RabbitMQ in a cluster. Thanks, Muthu -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5749588.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq
Hi, If you use camel 2.13.0, you can specify the option of BridgeEndpoint=true, then camel rabbitmq can ignore the message header which are set by camel rabbitmq consumer. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On March 27, 2014 at 10:50:06 PM, muthukumara...@gmail.com (muthukumara...@gmail.com) wrote: > Hi Willem, > > As I removed all of the rabbitmq headers using this pattern "rabbitmq.*", > This ended up removed "rabbitmq.CONTENT_TYPE" and this is causing trouble > in converting the message to a Java Object on the consumer. > > Instead of removing all the rabbitmq headers, is there one or two specific > rabbitmq headers which causes Camel to keep sending same message to the > general.queue? > > If so I will exclude only that particular header. > > Thanks, > Muthu > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5749441.html > > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: camel-rabbitmq
Hi Willem, As I removed all of the rabbitmq headers using this pattern "rabbitmq.*", This ended up removed "rabbitmq.CONTENT_TYPE" and this is causing trouble in converting the message to a Java Object on the consumer. Instead of removing all the rabbitmq headers, is there one or two specific rabbitmq headers which causes Camel to keep sending same message to the general.queue? If so I will exclude only that particular header. Thanks, Muthu -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5749441.html Sent from the Camel - Users mailing list archive at Nabble.com.
RE: camel-rabbitmq autoack=false
Willem,
I reverted the change below on a private copy of camel-rabbitmq in
RabbitMQConsumer.class, and reverting that change fixed my problem, allowing me
to NOT autoAck. Could you please consider reverting this fix in the code?
Here is a link to the commit:
https://github.com/apache/camel/commit/87a609c33bb7d0ddc078d2b4cb4027e290aefd82
Also, I noticed that 'isAutoAck()' in RabbitMQConsumer.class is being used as a
parameter in a call to channel.basicConsume() from doStart() in the same class.
This channel class, ChannelN.class, has a property, noAck, which syntactically
reverses the logic of isAutoAck(). I suspect that this use of isAutoAck() in
doStart() should be notted ('!') because the logic in ChannelN.class is
reversed (isAutoAck verses noAck).
Thanks,
John
John H. Clark
Sr. Software Engineer
Digital Marketing Business Unit
Adobe Systems
385.345.1656
ext 51656 (in office)
johcl...@adobe.com
3900 Adobe Way
Lehi, UT 84043 USA
www.adobe.com
-Original Message-
From: John H. Clark
Sent: Wednesday, March 12, 2014 10:40 AM
To: users@camel.apache.org
Cc: 'willem.ji...@gmail.com'
Subject: RE: camel-rabbitmq autoack=false
Willem,
I updated to 2.12.3, and still have the same problem. I believe there is a bug
in the code, it camel-rabbitmq-2.12.3.jar, RabbitMQConsumer.class, line 126:
if (!consumer.endpoint.isAutoAck()) {
log.trace("Acknowledging receipt [delivery_tag={}]",
deliveryTag);
channel.basicAck(deliveryTag, false);
}
I believe there should NOT be a '!' on the check for isAutoAck().
I tried setting autoAck to true when creating the endpoint, but the message
still gets acknowledged. I believe this is because there is another use of
isAutoAck() further down in the same module where it is passed through to an
AMQP module.
Regardless of whether or not this analysis is correct, when I set autoAck to
false, my messages are still autoAck-ed.
What do you think?
Thanks,
John
John H. Clark
Sr. Software Engineer
Digital Marketing Business Unit
Adobe Systems
385.345.1656
ext 51656 (in office)
johcl...@adobe.com
3900 Adobe Way
Lehi, UT 84043 USA
www.adobe.com
-Original Message-
From: Willem Jiang [mailto:willem.ji...@gmail.com]
Sent: Monday, March 10, 2014 8:24 PM
To: users@camel.apache.org
Subject: Re: camel-rabbitmq autoack=false
Hi,
We have some autoack related issue in camel 2.12.1.
I just checked latest release camel 2.12.3’s code, the autoAck option is set
rightly.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On March 11, 2014 at 9:22:53 AM, John H. Clark (johcl...@adobe.com) wrote:
> I am creating an endpoint as follows using camel-rabbitmq (2.12.2).
> The endpoint works fine, but appears to be doing an acknowledge even though
> autoAck=false.
>
> String endpoint = "rabbitmq://" + host + ":" + port + "/" + exchange +
> "?username=" + username
> + "&password=" + password
> + "&queue=" + queue + "&vhost=" + vhost + "&routingKey=" + routingKey +
> "&exchangeType=fanout"
> + "&durable=true&autoDelete=false&autoAck=false";
>
> Any ideas or are others experiencing something similar? If it is a
> bug, any ideas for a workaround?
>
> Thanks,
>
> John H. Clark
>
>
>
>
RE: camel-rabbitmq autoack=false
Willem,
I updated to 2.12.3, and still have the same problem. I believe there is a bug
in the code, it camel-rabbitmq-2.12.3.jar, RabbitMQConsumer.class, line 126:
if (!consumer.endpoint.isAutoAck()) {
log.trace("Acknowledging receipt [delivery_tag={}]",
deliveryTag);
channel.basicAck(deliveryTag, false);
}
I believe there should NOT be a '!' on the check for isAutoAck().
I tried setting autoAck to true when creating the endpoint, but the message
still gets acknowledged. I believe this is because there is another use of
isAutoAck() further down in the same module where it is passed through to an
AMQP module.
Regardless of whether or not this analysis is correct, when I set autoAck to
false, my messages are still autoAck-ed.
What do you think?
Thanks,
John
John H. Clark
Sr. Software Engineer
Digital Marketing Business Unit
Adobe Systems
385.345.1656
ext 51656 (in office)
johcl...@adobe.com
3900 Adobe Way
Lehi, UT 84043 USA
www.adobe.com
-Original Message-
From: Willem Jiang [mailto:willem.ji...@gmail.com]
Sent: Monday, March 10, 2014 8:24 PM
To: users@camel.apache.org
Subject: Re: camel-rabbitmq autoack=false
Hi,
We have some autoack related issue in camel 2.12.1.
I just checked latest release camel 2.12.3’s code, the autoAck option is set
rightly.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On March 11, 2014 at 9:22:53 AM, John H. Clark (johcl...@adobe.com) wrote:
> I am creating an endpoint as follows using camel-rabbitmq (2.12.2).
> The endpoint works fine, but appears to be doing an acknowledge even though
> autoAck=false.
>
> String endpoint = "rabbitmq://" + host + ":" + port + "/" + exchange +
> "?username=" + username
> + "&password=" + password
> + "&queue=" + queue + "&vhost=" + vhost + "&routingKey=" + routingKey +
> "&exchangeType=fanout"
> + "&durable=true&autoDelete=false&autoAck=false";
>
> Any ideas or are others experiencing something similar? If it is a
> bug, any ideas for a workaround?
>
> Thanks,
>
> John H. Clark
>
>
>
>
Re: camel-rabbitmq autoack=false
Hi, We have some autoack related issue in camel 2.12.1. I just checked latest release camel 2.12.3’s code, the autoAck option is set rightly. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On March 11, 2014 at 9:22:53 AM, John H. Clark (johcl...@adobe.com) wrote: > I am creating an endpoint as follows using camel-rabbitmq (2.12.2). The > endpoint works > fine, but appears to be doing an acknowledge even though autoAck=false. > > String endpoint = "rabbitmq://" + host + ":" + port + "/" + exchange + > "?username=" + username > + "&password=" + password > + "&queue=" + queue + "&vhost=" + vhost + "&routingKey=" + routingKey + > "&exchangeType=fanout" > + "&durable=true&autoDelete=false&autoAck=false"; > > Any ideas or are others experiencing something similar? If it is a bug, any > ideas for a > workaround? > > Thanks, > > John H. Clark > > > >
Re: camel-rabbitmq
Thanks Willem -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5744410.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq
In camel we have a rule that message header can override the setting of endpoint. When consumer receives the message, it puts some headers which key is start with “rabbitmq.”. As the producer always prefer the message header setting over the endpoint setting, the producer sends the message to general.queue. Then the consumer get a new message and route it to the producer. That could explain why you saw the camel keeps sending same message to the general.queue. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On December 6, 2013 at 12:34:57 AM, muthukumara...@gmail.com (muthukumara...@gmail.com) wrote: > >Thanks Willem for the quick response. > >Your suggestion resolved my issue. Can you please explain why this issue >happened and how this fixed it? > >Thanks, >Muthu > > > >-- >View this message in context: >http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5744374.html >Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: camel-rabbitmq
Thanks Willem for the quick response. Your suggestion resolved my issue. Can you please explain why this issue happened and how this fixed it? Thanks, Muthu -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-routing-issue-tp5744371p5744374.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq
You need to remove the message header which is start with “rabbitmq.” just like this -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On December 5, 2013 at 11:19:29 PM, muthukumara...@gmail.com (muthukumara...@gmail.com) wrote: > >Hi > >I am using Camel 2.12.1 and Rabbitmq 3.2.1 > >I have defined the following route in my spring config and every time I send >a message to "general.topic" I would expect the message would end up in >"scheduler.queue" > >But this doesn't happen it puts the message back to "general.queue" in a >loop. I send only one message to "general.topic" it keeps putting the same >message multiple times in the "general.queue" until I stop the Camel server. > >/ > > >>uri="rabbitmq://localhost/general.topic?queue=general.queue&routingKey=general.queue&exchangeType=topic&username=guest&password=guest&autoDelete=false&durable=true" >/> >>uri="rabbitmq://localhost/scheduler.topic?queue=scheduler.queue&routingKey=scheduler.queue&exchangeType=topic&username=guest&password=guest&autoDelete=false&durable=true" >/> > >/ > >If I change the "to" route as "/>uri="log:com.mycompany.order?level=INFO"/>/" >it logs the message properly in >the log and only once. > >Any help or suggestions?. > >Thanks. >Muthu > > > > > > >-- >View this message in context: >http://camel.465427.n5.nabble.com/camel-rabbitmq-tp5744371.html >Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: Camel RabbitMQ component - Increasing File Descriptors
I just checked the code, for the dynamicRouter the endpoint is cached, but the
producer is not cached.
Please feel free to create a JIRA about it.
BTW, I want to know the difference between the RabbitMQ connection and channel
to decide if we need to create channel per producer.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Thursday, November 7, 2013 at 3:45 PM, Mayank Mishra wrote:
> Thanks Willem,
>
> I think creating channel per request is not a problem, but creating is
> connection for each request will be a problem.
>
> Do we require to create a producer each time if we encounter endpoint
> (having same identifier) declaration. If this is the expected behavior
> then yes we can have caching for connection in the producer.
>
> Can I create a JIRA for this?
>
> With regards,
> Mayank
>
> On Thursday 07 November 2013 01:05 PM, Willem jiang wrote:
> > I just checked the code of RabbitMQProducer, it create new connection and
> > channel when creating the producer.
> > I think we need to cache the connection or channel to avoid creating a new
> > connection per new Producer.
> >
> > In you case if there is no much of RabbitMQ Endpoint, you can setup the
> > route like this to avoid creating producer dynamically.
> >
> > from(“direct:queue1”).to("rabbitmq://xxx.xxx.xxx.xxx
> > (http://xxx.xxx.xxx.xxx):queue1")
> >
> > from(“direct:queue2”).to("rabbitmq://xxx.xxx.xxx.xxx
> > (http://xxx.xxx.xxx.xxx):queue2”)
> >
> > The you can set up dynamic slip endpoint uri as “direct:queue1”,
> > “direct:queue2”
> >
> > --
> > Willem Jiang
> >
> > Red Hat, Inc.
> > Web: http://www.redhat.com
> > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
> > (English)
> > http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> >
> >
> >
> > On Thursday, November 7, 2013 at 2:27 PM, Mayank Mishra wrote:
> >
> > > Hi all,
> > >
> > > We are using Camel RabbitMQ component (v2.12.0) to publish message on
> > > RabbitMQ.
> > >
> > >
> > > We are using dynamic slip router to publish the messages to the endpoint
> > > (like, rabbitmq://xxx.xxx.xxx.xxx
> > > (http://xxx.xxx.xxx.xxx):/) something like below,
> > >
> > > .dynamicRouter(method(ServiceRouter.class, "slip"))
> > >
> > > As the message are getting published we saw heavy increase in the number
> > > of open FDs on RabbitMQ admin.
> > >
> > > Looking into the code, it seems with each time a producer will be created
> > > (overridden DefaultEndpoint's createProducer() method) a new connection
> > > to RabbitMQ will get created, which is going to increase FDs.
> > >
> > > Please let me know if there is some other way of doing above or there is
> > > a bug with the component.
> > >
> > > With regards,
> > > Mayank
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > NOTE: This message may contain information that is confidential,
> > > proprietary, privileged or otherwise protected by law. The message is
> > > intended solely for the named addressee. If received in error, please
> > > destroy and notify the sender. Any use of this email is prohibited when
> > > received in error. Impetus does not represent, warrant and/or guarantee,
> > > that the integrity of this communication has been maintained nor that the
> > > communication is free of errors, virus, interception or interference.
>
>
>
>
>
>
>
>
>
> NOTE: This message may contain information that is confidential, proprietary,
> privileged or otherwise protected by law. The message is intended solely for
> the named addressee. If received in error, please destroy and notify the
> sender. Any use of this email is prohibited when received in error. Impetus
> does not represent, warrant and/or guarantee, that the integrity of this
> communication has been maintained nor that the communication is free of
> errors, virus, interception or interference.
Re: Camel RabbitMQ component - Increasing File Descriptors
Thanks Willem,
I think creating channel per request is not a problem, but creating is
connection for each request will be a problem.
Do we require to create a producer each time if we encounter endpoint
(having same identifier) declaration. If this is the expected behavior
then yes we can have caching for connection in the producer.
Can I create a JIRA for this?
With regards,
Mayank
On Thursday 07 November 2013 01:05 PM, Willem jiang wrote:
I just checked the code of RabbitMQProducer, it create new connection and
channel when creating the producer.
I think we need to cache the connection or channel to avoid creating a new
connection per new Producer.
In you case if there is no much of RabbitMQ Endpoint, you can setup the route
like this to avoid creating producer dynamically.
from(“direct:queue1”).to("rabbitmq://xxx.xxx.xxx.xxx
(http://xxx.xxx.xxx.xxx):queue1")
from(“direct:queue2”).to("rabbitmq://xxx.xxx.xxx.xxx
(http://xxx.xxx.xxx.xxx):queue2”)
The you can set up dynamic slip endpoint uri as “direct:queue1”, “direct:queue2”
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Thursday, November 7, 2013 at 2:27 PM, Mayank Mishra wrote:
Hi all,
We are using Camel RabbitMQ component (v2.12.0) to publish message on RabbitMQ.
We are using dynamic slip router to publish the messages to the endpoint (like,
rabbitmq://xxx.xxx.xxx.xxx (http://xxx.xxx.xxx.xxx):/) something
like below,
.dynamicRouter(method(ServiceRouter.class, "slip"))
As the message are getting published we saw heavy increase in the number of
open FDs on RabbitMQ admin.
Looking into the code, it seems with each time a producer will be created
(overridden DefaultEndpoint's createProducer() method) a new connection to
RabbitMQ will get created, which is going to increase FDs.
Please let me know if there is some other way of doing above or there is a bug
with the component.
With regards,
Mayank
NOTE: This message may contain information that is confidential, proprietary,
privileged or otherwise protected by law. The message is intended solely for
the named addressee. If received in error, please destroy and notify the
sender. Any use of this email is prohibited when received in error. Impetus
does not represent, warrant and/or guarantee, that the integrity of this
communication has been maintained nor that the communication is free of errors,
virus, interception or interference.
NOTE: This message may contain information that is confidential, proprietary,
privileged or otherwise protected by law. The message is intended solely for
the named addressee. If received in error, please destroy and notify the
sender. Any use of this email is prohibited when received in error. Impetus
does not represent, warrant and/or guarantee, that the integrity of this
communication has been maintained nor that the communication is free of errors,
virus, interception or interference.
Re: Camel RabbitMQ component - Increasing File Descriptors
I just checked the code of RabbitMQProducer, it create new connection and
channel when creating the producer.
I think we need to cache the connection or channel to avoid creating a new
connection per new Producer.
In you case if there is no much of RabbitMQ Endpoint, you can setup the route
like this to avoid creating producer dynamically.
from(“direct:queue1”).to("rabbitmq://xxx.xxx.xxx.xxx
(http://xxx.xxx.xxx.xxx):queue1")
from(“direct:queue2”).to("rabbitmq://xxx.xxx.xxx.xxx
(http://xxx.xxx.xxx.xxx):queue2”)
The you can set up dynamic slip endpoint uri as “direct:queue1”,
“direct:queue2”
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Thursday, November 7, 2013 at 2:27 PM, Mayank Mishra wrote:
> Hi all,
>
> We are using Camel RabbitMQ component (v2.12.0) to publish message on
> RabbitMQ.
>
>
> We are using dynamic slip router to publish the messages to the endpoint
> (like, rabbitmq://xxx.xxx.xxx.xxx (http://xxx.xxx.xxx.xxx):/)
> something like below,
>
> .dynamicRouter(method(ServiceRouter.class, "slip"))
>
> As the message are getting published we saw heavy increase in the number of
> open FDs on RabbitMQ admin.
>
> Looking into the code, it seems with each time a producer will be created
> (overridden DefaultEndpoint's createProducer() method) a new connection to
> RabbitMQ will get created, which is going to increase FDs.
>
> Please let me know if there is some other way of doing above or there is a
> bug with the component.
>
> With regards,
> Mayank
>
>
>
>
>
>
>
>
>
>
>
>
> NOTE: This message may contain information that is confidential, proprietary,
> privileged or otherwise protected by law. The message is intended solely for
> the named addressee. If received in error, please destroy and notify the
> sender. Any use of this email is prohibited when received in error. Impetus
> does not represent, warrant and/or guarantee, that the integrity of this
> communication has been maintained nor that the communication is free of
> errors, virus, interception or interference.
Re: Camel-rabbitmq - how to handle endpoint not available?
Hi Is it only rabbitmq endpoints as producers you use (eg .to rabbit) and not consumers? 1) Some components has an lazyCreateSession option that will only create the connection on demand. So in that case the route will be able to startup, and on 1st message the producer will create a connection and if it fails, then the Camel error handler can react. On the consumer side its more tricky as you would need a background job that re-attempts to get a connection to the rabbit broker. Maybe we can add such functionality to camel-rabbitmq. 2) All this failover and reconnect stuff is built-in out of the box with Apache ActiveMQ on its client side. Wonder if rabbit don't have that as well? So its a matter of configuring it using some api on the rabbit client, and then expose that api/options to the camel-rabbit component, so people can configure it. So maybe check for #2 first and if there is no such thing from rabbit client, we can take a look at #1 On Tue, Nov 5, 2013 at 11:56 PM, Sell, Matt wrote: > > I'm trying to use Camel embedded into an application (Spring configured) to > push files from a local directory to an instance of RabbitMQ. It's been > working well so far, except in the case where RabbitMQ is not available for > some reason (network outage, maintenance, etc.), and our application is > started. In this case, Camel is unable to start because the endpoint is not > available (FailedToCreateProducerException resulting from a "connection > refused"). > > Is it possible to recover from such an error? The ideal situation would be to > allow a configuration where redelivery attempts could be made in the hope > that RabbitMQ will become available again. Our application that is using > Camel is deployed on several hundred workstations and it would be necessary > to configure Camel in such a way that recovery (reconnect to Rabbit) would be > automatic. > > Any ideas? There doesn't appear to be a way to configure Camel using the > available Exception handling strategies to operate in this manner, although > my guess is that I've missed something. > > Thanks! > > > > - Matt > > -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: camel-rabbitmq : not able to publish messages
I don’t see any errors in the logs, it’s only info/debug logs (given below). I even created the exchange (direct durable) and the queue (durable) manually. This only helped in establishing the connection and also the idle channel was created from camel but no message was published to the queue. I used rabbitmq client v3.1.3 this time. [main] DefaultCamelContextDEBUG Adding routes from builder: Routes: [] [main] DefaultCamelContextINFO Apache Camel 2.12.1 (CamelContext: camel-1) is starting [main] DefaultCamelContextDEBUG Using ClassResolver=org.apache.camel.impl.DefaultClassResolver@7946738, PackageScanClassResolver=org.apache.camel.impl.DefaultPackageScanClassResolver@2004916b, ApplicationContextClassLoader=sun.misc.Launcher$AppClassLoader@70cfaf6e [main] ManagedManagementStrategy INFO JMX is enabled [main] DefaultManagementAgent DEBUG Starting JMX agent on server: com.sun.jmx.mbeanserver.JmxMBeanServer@4f8429d6 [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=context,name="camel-1" [main] TimerListenerManager DEBUG Added TimerListener: org.apache.camel.management.mbean.ManagedCamelContext@7302d823 [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=DefaultTypeConverter [main] AnnotationTypeConverterLoader DEBUG Found 3 packages with 15 @Converter classes to load [main] AnnotationTypeConverterLoader DEBUG Loading file META-INF/services/org/apache/camel/TypeConverter to retrieve list of packages, from url: jar:file:/C:/Users/shanmukv/.m2/repository/org/apache/camel/camel-core/2.12.1/camel-core-2.12.1.jar!/META-INF/services/org/apache/camel/TypeConverter [main] AnnotationTypeConverterLoader DEBUG Loading file META-INF/services/org/apache/camel/TypeConverter to retrieve list of packages, from url: jar:file:/C:/Users/shanmukv/.m2/repository/org/apache/activemq/activemq-all/5.8.0/activemq-all-5.8.0.jar!/META-INF/services/org/apache/camel/TypeConverter [main] AnnotationTypeConverterLoader DEBUG Loading file META-INF/services/org/apache/camel/TypeConverter to retrieve list of packages, from url: jar:file:/C:/Users/shanmukv/.m2/repository/org/apache/camel/camel-spring/2.12.1/camel-spring-2.12.1.jar!/META-INF/services/org/apache/camel/TypeConverter [main] AnnotationTypeConverterLoader DEBUG Loaded 3 @Converter classes [main] DefaultTypeConverter INFO Loaded 179 type converters [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=EndpointRegistry [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=DefaultExecutorServiceManager [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=SharedProducerServicePool [main] SharedProducerServicePool DEBUG Starting service pool: org.apache.camel.impl.SharedProducerServicePool@51c93bea [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=DefaultInflightRepository [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=DefaultShutdownStrategy [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=services,name=DefaultPackageScanClassResolver [main] DefaultCamelContextDEBUG Using ComponentResolver: org.apache.camel.impl.DefaultComponentResolver@48caff01 to resolve component with name: file [main] DefaultComponentResolver DEBUG Found component: file in registry: null [main] DefaultComponentResolver DEBUG Found component: file via type: org.apache.camel.component.file.FileComponent via: META-INF/services/org/apache/camel/component/file [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=components,name="file" [main] DefaultComponent DEBUG Creating endpoint uri=[file://src/data], path=[src/data] [main] DefaultCamelContextDEBUG file://src/data converted to endpoint: Endpoint[file://src/data] by component: org.apache.camel.component.file.FileComponent@70b891ad [main] DefaultManagementAgent DEBUG Registered MBean with ObjectName: org.apache.camel:context=[hostname]/camel-1,type=endpoints,name="file://src/data" [main] DefaultCamelContextDEBUG Using ComponentResolver: org.apache.camel.impl.DefaultComponentResolver@48caff01 to resolve component with name: rabbitmq [main] DefaultComponentResolver DEBUG Found component: rabbitmq in registry: null [main] DefaultComponentResolver DEBUG Found com
Re: camel-rabbitmq : not able to publish messages
Camel uses the rabbitmq libs, v3.1.3, so should support 0-9-1/0-9/0-8 protocols. The camel producer will not create the exchange/queue. Do you not see any exceptions in the log? On Thu, Oct 17, 2013 at 8:53 AM, tsv wrote: > Hi Reji, > The queue name is in the endpoint option '&queue=myqueue&'. By removing > noop=true did not help, it’s behaving the same, rabbitmq connection is > opened and no channel, exchange, queue or message is created. I even > replaced RabbitMQ Client version to:2.8.2 from: 3.1.5 this also has no > effect. > > Is the camel-rabbitmq component support AMQP versions 0-9-1 or 0-9 or 0-8 > or > its just 1.0 or 0.10. As RabbitMQ will perform protocol negotiation with > the > clients implementing 0-9-1, 0-9 and 0-8 only. > > Thanks, > tsv > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707p5741774.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
Re: camel-rabbitmq : not able to publish messages
Hi Reji, The queue name is in the endpoint option '&queue=myqueue&'. By removing noop=true did not help, it’s behaving the same, rabbitmq connection is opened and no channel, exchange, queue or message is created. I even replaced RabbitMQ Client version to:2.8.2 from: 3.1.5 this also has no effect. Is the camel-rabbitmq component support AMQP versions 0-9-1 or 0-9 or 0-8 or its just 1.0 or 0.10. As RabbitMQ will perform protocol negotiation with the clients implementing 0-9-1, 0-9 and 0-8 only. Thanks, tsv -- View this message in context: http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707p5741774.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq : not able to publish messages
Hey
What is the name of the queue? And also try removing noop =true and let me
know how it behaves
cheers
Reji
"tsv [via Camel]" wrote:
>
>
>Greetings,
>
>I am using camel-rabbitmq component to publish messages to rabbitmq broker.
>But I see my route opens a connection in rabbitmq server (viewed from
>rabbitmq web admin management console) but never creates a channel,
>exchange, queue and the message.
>
>Here is my route config:
>from("file:src/data?noop=true").to("rabbitmq://myhost.com:5672/camel.exchange?username=guest&password=guest&vhost=myvhost&queue=myqueue&routingKey=myqueue.key");
>
>I am expecting the producer is going to declare the exchange (may be the
>default exchange type), and create the queue and publish the message. But it
>seems nothing is happening, just connection is opened and I don't see any
>errors in the debug log. Can anybody let me know what options in the config
>I am missing or what possibly is wrong in the route.
>
>Camel version: 2.12.1
>camel-rabbitmq component version: 2.12.1
>RabbitMQ Server version: RabbitMQ 2.8.2 on Erlang R14B01
>RabbitMQ Client version: 3.1.5
>src/data folder has a xml file
>
>Thanks
>
>
>
>
>___
>If you reply to this email, your message will be added to the discussion below:
>http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707.html
>
>To unsubscribe from Camel - Users, visit
>http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=Y29udGFjdHJlamlAZ21haWwuY29tfDQ2NTQyOHwxMDA0OTE4MjMz
--
View this message in context:
http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707p5741717.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-rabbitmq : not able to publish messages
Hi
Could you tell me where have you mentioned the name of the Queue?
Alternatively please let me know how it behaves when you remove noop-true
Cheers
Reji
On Wed, Oct 16, 2013 at 3:45 PM, tsv [via Camel] <
ml-node+s465427n5741707...@n5.nabble.com> wrote:
> Greetings,
>
> I am using camel-rabbitmq component to publish messages to rabbitmq
> broker. But I see my route opens a connection in rabbitmq server (viewed
> from rabbitmq web admin management console) but never creates a channel,
> exchange, queue and the message.
>
> Here is my route config:
> from("file:src/data?noop=true").to("rabbitmq://
> myhost.com:5672/camel.exchange?username=guest&password=guest&vhost=myvhost&queue=myqueue&routingKey=myqueue.key");
>
>
> I am expecting the producer is going to declare the exchange (may be the
> default exchange type), and create the queue and publish the message. But
> it seems nothing is happening, just connection is opened and I don't see
> any errors in the debug log. Can anybody let me know what options in the
> config I am missing or what possibly is wrong in the route.
>
> Camel version: 2.12.1
> camel-rabbitmq component version: 2.12.1
> RabbitMQ Server version: RabbitMQ 2.8.2 on Erlang R14B01
> RabbitMQ Client version: 3.1.5
> src/data folder has a xml file
>
> Thanks
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707.html
> To unsubscribe from Camel - Users, click
> here
> .
> NAML
>
--
View this message in context:
http://camel.465427.n5.nabble.com/camel-rabbitmq-not-able-to-publish-messages-tp5741707p5741712.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel RabbitMQ from 2.12 snapshot - missing parameter type:direct
Hi Willem, Thanks for your quick reply. Thanks, Tushar -- View this message in context: http://camel.465427.n5.nabble.com/Camel-RabbitMQ-from-2-12-snapshot-missing-parameter-type-direct-tp5738013p5738026.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel RabbitMQ from 2.12 snapshot - missing parameter type:direct
Hi
Camel RabbitMQ doesn't support to set the type currently.
The type value is direct, with the code like this:
channel.exchangeDeclare(endpoint.getExchangeName(),
"direct",
endpoint.isDurable(),
endpoint.isAutoDelete(),
new HashMap());
I just found the below code doesn't follow the configuration of endpoint
hannel.queueDeclare(endpoint.getQueue(), true, false, false, null);
That is reason which causes the channel was closed.
I just updated the code, and push it into git central repo, please check it out
to verify the fix.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, August 27, 2013 at 12:51 PM, tushmish wrote:
> Hi,
>
> I am trying to use RabbitMQ component from Camel 2.12 Snapshot. I am trying
> to read messages from queue into camel exchange.
>
> Route definition
>
>
> uri="rabbitmq://localhost:5672/myExchange?durable=true&queue=myQueue&username=guest&password=guest&routingKey=aaa"/>
> method="getMessageFromBroker(org.apache.camel.Exchange)"/>
> http://in.yahoo.com)"/>
>
>
> getMessageFromBroker -> where the message body is read.
>
> In RabbitMQ - using Web Management console,
> Exchange - myExchange has been created. with type = direct, durable = true.
> Queue - myQueue has been created and binded to myexchange with routingKey =
> aaa.
>
> However, on loading the camel context, I get this error.
> channel error; reason: {#method(reply-code=406,
> reply-text=PRECONDITION_FAILED - cannot redeclare exchange 'myExchange' in
> vhost '/' with different type, durable, internal or autodelete value,
> class-id=40, method-id=10), null, ""}
>
> The error is self explicable. But I am not redeclaring myExchange here. I
> looked at the Options section here - http://camel.apache.org/rabbitmq.html.
> But I do not find an option for 'type'. May this be the problem ?
>
> What am I missing ?
>
> Thanks for your time.
>
> Tushar
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-RabbitMQ-from-2-12-snapshot-missing-parameter-type-direct-tp5738013.html
> Sent from the Camel - Users mailing list archive at Nabble.com
> (http://Nabble.com).
Re: camel-rabbitmq producer is not including the body
Hi, Thanks for reporting it. I just filled a JIRA[1] and committed a fix for it. [1]https://issues.apache.org/jira/browse/CAMEL-6617 -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Thursday, August 8, 2013 at 4:44 AM, dalewking wrote: > Trying to consume from rabbitmq using the camel-rabbitmq component and the > problem is the body of the message is not being passed down the line. > > Debugging and looking at the source, I see that in > RabbitMQConsumer.RabbitConsumer.handleDelivery that the body is being passed > into the method, but nothing is done with that parameter. > > An exchange is created from the envelope in > RabbitMQEndPoint.createRabbitExchange, that contains a DefaultMessage > instance for the in, but the only things set on the message are the routing > key, exchange name, and delivery tag headers. The body of the message is not > set and is therefore null. > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-rabbitmq-producer-is-not-including-the-body-tp5736952.html > Sent from the Camel - Users mailing list archive at Nabble.com > (http://Nabble.com).
Re: camel rabbitmq
I ran into this as well and can be worked around by adding this between your
from and to:
.setHeader(RabbitMQConstants.EXCHANGE_NAME).constant("A")
--
View this message in context:
http://camel.465427.n5.nabble.com/camel-rabbitmq-tp5736483p5736930.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel rabbitmq
Hi
Thanks for reporting. I am fixing this on master.
On Tue, Jul 30, 2013 at 12:43 PM, kiranreddykasa wrote:
> Hi
>
> I tried to use camel-rabbitmq component from 2.12 snapshot.
>
> Here is my route.
>
>
> from("netty:tcp://0.0.0.0:7000?textline=true").to("rabbitmq://localhost/A?routingKey=B&username=guest&password=guest");
>
> And I am getting null pointer exception.
>
>
> Here is full stacktrace
>
> Stacktrace
> ---
> java.lang.NullPointerException
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.process(RabbitMQProducer.java:51)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:123)
> at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:118)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:397)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:189)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:189)
> at
> org.apache.camel.component.netty.handlers.ServerChannelHandler.processAsynchronously(ServerChannelHandler.java:130)
> at
> org.apache.camel.component.netty.handlers.ServerChannelHandler.messageReceived(ServerChannelHandler.java:104)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
> at
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
> at
> org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:314)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
>
>
>
> -
> Regards
>
> kiran Reddy
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-rabbitmq-tp5736483.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
