Return-Path: X-Original-To: apmail-camel-issues-archive@minotaur.apache.org Delivered-To: apmail-camel-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 946059C67 for ; Thu, 17 May 2012 14:15:44 +0000 (UTC) Received: (qmail 96542 invoked by uid 500); 17 May 2012 14:15:44 -0000 Delivered-To: apmail-camel-issues-archive@camel.apache.org Received: (qmail 96500 invoked by uid 500); 17 May 2012 14:15:44 -0000 Mailing-List: contact issues-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list issues@camel.apache.org Received: (qmail 96487 invoked by uid 99); 17 May 2012 14:15:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2012 14:15:44 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2012 14:15:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id A97E8ABD2 for ; Thu, 17 May 2012 14:15:22 +0000 (UTC) Date: Thu, 17 May 2012 14:15:22 +0000 (UTC) From: "David Cifer (JIRA)" To: issues@camel.apache.org Message-ID: <1994014168.8742.1337264122696.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1637075147.8634.1337263030725.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (CAMEL-5282) Strange race condition in for SEDA, when shutting down in Camel 2.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CAMEL-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Cifer updated CAMEL-5282: ------------------------------- Description: We have file endpoints, with idemptotent file repository feeds into a SEDA chanel. Behind the SEDA is a solution, which can only deal one file at a time. If the system some reason shutdowns, than on restart we shouldn't consume already consumed files. If exception occurs, we shutdown our application. This behaviour assured by a unit test, which begin to fail when we introduce timeout=0 configuration. Here is the pseudo code: onException(RuntimeException.class).process(new ShutDown()); from("file:/tempfolder/files/?idempotent=true&noop=true&idempotentRepository=#repo&delay=1000") .inOut("seda:process?timeout=0"); from("seda:process").delay(1000).throwException(new RuntimeException("Testing with exception")); I use inOut so the file thread, waits for SEDA to acomplish. This serves as there is an exception happens behind seda side, by using DefaultErrorHandler strategy it propagates back to file endpoint and the sent file, won't be marked consumed. With 2.9.1 the files marked as consumed (meaning recorded in the idempotent repository) 90% of the times. I say % because sometimes the test passes without any issue. On 2.9.0 I wasn't able to reproduce the error. NOTE: When you remove the timeout, than behaviour will be fine was: We have file endpoints, with idemptotent file repository feeds into a SEDA chanel. Behind the SEDA is a solution, which can only deal one file at a time. If the system some reason shutdowns, than on restart we shouldn't consume already consumed files. If exception occurs, we shutdown our application. This behaviour assured by a unit test, which begin to fail when we introduce timeout=0 configuration. Here is the pseudo code: onException(RuntimeException.class).process(new ShutDown()); from("file:/tempfolder/files/?idempotent=true&noop=true&idempotentRepository=#repo&delay=1000") .inOut("seda:process?timeout=0"); from("seda:process").delay(1000).throwException(new RuntimeException("Testing with exception")); I use inOut so the file thread, waits for SEDA to acomplish. This serves as there is an exception happens behind seda side, by using DefaultErrorHandler strategy it propagates back to file endpoint and the sent file, won't be marked consumed. With 2.9.1 the files marked as consumed (meaning recorded in the idempotent repository) 90% of the times. I say % because sometimes the test passes without any issue. On 2.9.0 I wasn't able to reproduce the error. > Strange race condition in for SEDA, when shutting down in Camel 2.9.1 > --------------------------------------------------------------------- > > Key: CAMEL-5282 > URL: https://issues.apache.org/jira/browse/CAMEL-5282 > Project: Camel > Issue Type: Bug > Components: camel-core > Affects Versions: 2.9.1 > Environment: Windows XP, jdk1.6.0_29 > Reporter: David Cifer > Priority: Critical > Attachments: SedaTimeoutTest.java, TimeoutSetToDefault30SecSedaTimeoutTest.java > > > We have file endpoints, with idemptotent file repository feeds into a SEDA chanel. > Behind the SEDA is a solution, which can only deal one file at a time. > If the system some reason shutdowns, than on restart we shouldn't consume already consumed files. > If exception occurs, we shutdown our application. > This behaviour assured by a unit test, which begin to fail when we introduce timeout=0 configuration. > Here is the pseudo code: > onException(RuntimeException.class).process(new ShutDown()); > > from("file:/tempfolder/files/?idempotent=true&noop=true&idempotentRepository=#repo&delay=1000") > .inOut("seda:process?timeout=0"); > > from("seda:process").delay(1000).throwException(new RuntimeException("Testing with exception")); > I use inOut so the file thread, waits for SEDA to acomplish. This serves as there is an exception happens behind seda side, by using DefaultErrorHandler strategy it propagates back to file endpoint and the sent file, won't be marked consumed. > With 2.9.1 the files marked as consumed (meaning recorded in the idempotent repository) 90% of the times. I say % because sometimes the test passes without any issue. On 2.9.0 I wasn't able to reproduce the error. > NOTE: When you remove the timeout, than behaviour will be fine -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira