[
https://issues.apache.org/jira/browse/CAMEL-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rastislav Papp updated CAMEL-16707:
-----------------------------------
Description:
camel-rabbitmq component causes a connection leak when there is an error during
declaration of exchanges/queues (e.g. when an exchange with the same name but
different type already exists).
Problem lies in {{org.apache.camel.component.rabbitmq.RabbitConsumer}}:
{code:java}
RabbitConsumer(RabbitMQConsumer consumer) {
// super(channel);
this.consumer = consumer;
try {
Connection conn = consumer.getConnection();
this.channel = openChannel(conn);
} catch (IOException | TimeoutException e) {
LOG.warn("Unable to open channel for RabbitMQConsumer. Continuing
and will try again", e);
}
}
//...
private Channel openChannel(Connection conn) throws IOException {
Channel channel = //... channel gets created
//...
if (consumer.getEndpoint().isDeclare()) {
consumer.getEndpoint().declareExchangeAndQueue(channel);
}
return channel;
}
{code}
if {{declareExchangeAndQueue}} gets called, and if it throws an exception (e.g.
because the exchange is already declared with different configuration) the
exception is caught and consumed in the constructor, and the channel is never
closed. I think the exception should be propagated in this case, because it is
not recoverable (or at least there should be an option for this). It would also
cause the app startup to fail, which would be a good thing in this case.
was:
camel-rabbitmq component causes a connection leak when there is an error during
declaration of exchanges/queues (e.g. when an exchange with the same name but
different type already exists).
Problem lies in {{org.apache.camel.component.rabbitmq.RabbitConsumer}}:
{code:java}
RabbitConsumer(RabbitMQConsumer consumer) {
// super(channel);
this.consumer = consumer;
try {
Connection conn = consumer.getConnection();
this.channel = openChannel(conn);
} catch (IOException | TimeoutException e) {
LOG.warn("Unable to open channel for RabbitMQConsumer. Continuing
and will try again", e);
}
}
//...
private Channel openChannel(Connection conn) throws IOException {
Channel channel = //... channel gets created
//...
if (consumer.getEndpoint().isDeclare()) {
consumer.getEndpoint().declareExchangeAndQueue(channel);
}
return channel;
}
{code}
if {{declareExchangeAndQueue}} gets called, and if it throws an exception the
exception is caught and consumed in the constructor, and the channel is never
closed. I think the exception should be propagated in this case, because it is
not recoverable (or at least there should be an option for this). It would also
cause the app startup to fail, which would be a good thing in this case.
> camel-rabbitmq connection leak on error during 'declare'
> --------------------------------------------------------
>
> Key: CAMEL-16707
> URL: https://issues.apache.org/jira/browse/CAMEL-16707
> Project: Camel
> Issue Type: Bug
> Components: camel-rabbitmq
> Affects Versions: 3.6.0
> Reporter: Rastislav Papp
> Priority: Major
>
> camel-rabbitmq component causes a connection leak when there is an error
> during declaration of exchanges/queues (e.g. when an exchange with the same
> name but different type already exists).
> Problem lies in {{org.apache.camel.component.rabbitmq.RabbitConsumer}}:
> {code:java}
> RabbitConsumer(RabbitMQConsumer consumer) {
> // super(channel);
> this.consumer = consumer;
> try {
> Connection conn = consumer.getConnection();
> this.channel = openChannel(conn);
> } catch (IOException | TimeoutException e) {
> LOG.warn("Unable to open channel for RabbitMQConsumer. Continuing
> and will try again", e);
> }
> }
> //...
> private Channel openChannel(Connection conn) throws IOException {
> Channel channel = //... channel gets created
> //...
> if (consumer.getEndpoint().isDeclare()) {
> consumer.getEndpoint().declareExchangeAndQueue(channel);
> }
> return channel;
> }
> {code}
> if {{declareExchangeAndQueue}} gets called, and if it throws an exception
> (e.g. because the exchange is already declared with different configuration)
> the exception is caught and consumed in the constructor, and the channel is
> never closed. I think the exception should be propagated in this case,
> because it is not recoverable (or at least there should be an option for
> this). It would also cause the app startup to fail, which would be a good
> thing in this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
