Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Tue, 5 Apr 2016 09:23:25 +0000 (UTC)
From: "Andrea Cosentino (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12955753.1459774856000.136478.1459848205575@Atlassian.JIRA>
In-Reply-To: <JIRA.12955753.1459774856000@Atlassian.JIRA>
References: <JIRA.12955753.1459774856000@Atlassian.JIRA>
 <JIRA.12955753.1459774856876@arcas>
Subject: [jira] [Commented] (CAMEL-9812) Camel leaves Kafka consumers
 running after shutdown
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CAMEL-9812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15225953#comment-15225953 ] 

Andrea Cosentino commented on CAMEL-9812:
-----------------------------------------

It seems we weren't closing the consumer. Now it should be ok.

I guess we should take a look to Consumer Group to make possible the use of multiple consumers on the same topics.

> Camel leaves Kafka consumers running after shutdown
> ---------------------------------------------------
>
>                 Key: CAMEL-9812
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9812
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-kafka
>    Affects Versions: 2.17.0
>         Environment: wildfly 10
> Java 1.8
> Camel: 2.17.0
>            Reporter: Jose Luis Pedrosa
>            Assignee: Andrea Cosentino
>             Fix For: 2.17.1, 2.18.0
>
>         Attachments: kafkaThreadStack.png
>
>
> After shutting down a camel context, there are still threads running kafka consumers. 
> In the logs after the shutdown I can see:
> {noformat}
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: ucms-camel-ctx) uptime 25.047 seconds
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: ucms-camel-ctx) is shutdown in 0.856 seconds
> 14:45:57,494 INFO  [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean] (ServerService Thread Pool -- 81) Closing JPA EntityManagerFactory for persistence unit 'default'
> 14:45:57,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment ucms-wildfly-container-3.0.1-SNAPSHOT.war (runtime-name: ucms-wildfly-container-3.0.1-SNAPSHOT.war) in 1098ms
> 14:45:57,906 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /opt/wildfly/standalone/data/content/20/13979a02e4b4ec178461d06c2de59fbf424215/content
> 14:45:57,916 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "ucms-wildfly-container-3.0.1-SNAPSHOT.war" (runtime-name: "ucms-wildfly-container-3.0.1-SNAPSHOT.war")
> 14:46:24,972 INFO  [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel (ucms-camel-ctx) thread #0 - KafkaTopic[ucmsControlTopic]) Marking the coordinator 2147483647 dead.
> 14:46:26,467 INFO  [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel (ucms-camel-ctx) thread #2 - KafkaTopic[TOPIC1]) Marking the coordinator 2147483647 dead.
> {noformat}
> So in theory the context is stopped, but I can see threads running with the polling of the sockets of kafka consumers (see attached immage).
> This deployed in an application server (wilfly in my case), causes a lot of issues, because apps get deployed and undeployed without stopping the  JVM, but threads from previous deployments are left there.
> Please also bear in mind that kafka (9.0.1) throws warning messages due to the fact that un expected config items are thrown to the kafka consumer properties.
> {noformat}
> 14:45:33,840 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration sasl.kerberos.ticket.renew.window.factor = 0.8 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration sasl.kerberos.kinit.cmd = /usr/bin/kinit was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration sasl.kerberos.ticket.renew.jitter = 0.05 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.keystore.type = JKS was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.trustmanager.algorithm = PKIX was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration sasl.kerberos.min.time.before.relogin = 60000 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.protocol = TLS was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.enabled.protocols = TLSv1.2,TLSv1.1,TLSv1 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.truststore.type = JKS was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] (ServerService Thread Pool -- 76) The configuration ssl.keymanager.algorithm = SunX509 was supplied but isn't a known config.
> {noformat}
> Thanks!


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)