Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D562DDD36 for ; Fri, 20 Jul 2012 14:26:47 +0000 (UTC) Received: (qmail 41983 invoked by uid 500); 20 Jul 2012 14:26:47 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 41690 invoked by uid 500); 20 Jul 2012 14:26:46 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 41150 invoked by uid 99); 20 Jul 2012 14:26:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2012 14:26:45 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 128.130.2.110 is neither permitted nor denied by domain of marco.zapletal@gmail.com) Received: from [128.130.2.110] (HELO mr.tuwien.ac.at) (128.130.2.110) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jul 2012 14:26:37 +0000 Received: from [192.168.168.136] (fortinat.ifs.tuwien.ac.at [128.131.167.8]) by mr.tuwien.ac.at (8.13.7/8.13.7) with ESMTP id q6KEQEqK006247 for ; Fri, 20 Jul 2012 16:26:15 +0200 (MEST) Message-ID: <50096A6F.8070903@gmail.com> Date: Fri, 20 Jul 2012 16:25:51 +0200 From: Marco Zapletal User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: users@camel.apache.org Subject: Camel ActiveMQ consumers do not consume after restart Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Virus-Checked: Checked by ClamAV on apache.org Hi folks, We have an application where we have two Camel contexts (C1, C2) which exchange messages via two queues (Q1, Q2). These queues are located on the same ActiveMQ broker. Thereby, the message flow goes as follows: C1 -> Q1 -> C2 C2 -> Q2 -> C1 C2 uses furthermore some "internal" queues on the AMQ broker, but I guess they are not relevant to the problem. The issue we are facing can be described as follows and happens only when C1 or C2 go down or have to be restarted - In case, no messages are produced of either C1/C2 while the other one restarts, everything is fine - i.e., there is no problem with consuming messages - In case, messages are produced of either C1/C2 and are put in the respective queue, during the absence of the other Camel application, we gonna face problems with consuming messages from the queues. We have especially tested this scenario by stopping C2. C1 produces messages to Q1. Then we restart C2 again and (almost) nothing happened. - By almost I mean, that the context of C2 starts up without errors. What is also observed is that when we have 1 concurrentConsumer defined in the AMQ consumer configuration in C2, 1 message is consumed (if 3 concurrentConsumers are defined, 3 messages are consumed). Afterwards, consumption stops. - When restarting C2 again, 1 message is consumed from Q1 (in case of 1 concurrentConsumer) - C2 exposes also two CXF services as producers of routes. Both of the two routes have one of those "internal" AMQ queues as their final destination. When we want to access their respective WSDL URL, the request hangs. - We have an admin Web application monitoring C2 via JMX. The admin application hangs due to no response from C2's JMX services (although the C2 context starts up properly according to the logs). - Nothing special can be seen in the logs. We examined the logs on DEBUG level (on Camel as well as on AMQ side) and nothing special could be seen. - We went back to a rather base config. No transactions, no connection pools, no caching of consumers/producers. We have experimented with the prefetch (setting it to 1 or even 0) without success. - In order to reach proper behavior again, Q1/Q2 (and maybe even the "internal queues of C2) have to be purged. Then C2 has be to be restarted again. After this procedure, message passing is back to normal. Sorry for the long post, but I want to describe the problem as detailed as possible. Since we have been working on this now for days any help would be highly appreciated. Thanks and best regards, Marco