Return-Path: X-Original-To: apmail-storm-user-archive@minotaur.apache.org Delivered-To: apmail-storm-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E61A010C87 for ; Fri, 4 Apr 2014 10:58:36 +0000 (UTC) Received: (qmail 19149 invoked by uid 500); 4 Apr 2014 10:58:36 -0000 Delivered-To: apmail-storm-user-archive@storm.apache.org Received: (qmail 18506 invoked by uid 500); 4 Apr 2014 10:58:33 -0000 Mailing-List: contact user-help@storm.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@storm.incubator.apache.org Delivered-To: mailing list user@storm.incubator.apache.org Received: (qmail 18495 invoked by uid 99); 4 Apr 2014 10:58:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 10:58:32 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of raymond.poling@citi.com designates 67.231.145.106 as permitted sender) Received: from [67.231.145.106] (HELO mx0a-00123c01.pphosted.com) (67.231.145.106) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 10:58:24 +0000 Received: from pps.filterd (m0008097 [127.0.0.1]) by mx0a-00123c02.pphosted.com (8.14.5/8.14.5) with SMTP id s34At3xm007798 for ; Fri, 4 Apr 2014 10:58:01 GMT Received: from mail.citigroup.com (smtpoutbound.citigroup.com [192.193.193.15]) by mx0a-00123c02.pphosted.com with ESMTP id 1jr69akjur-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 04 Apr 2014 10:58:01 +0000 Received: from imbhub-mw34.nam.nsroot.net (namdlpdimpsw05.nam.nsroot.net [153.40.172.111]) by smtpinbound.citigroup.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s34AvSVm029055 for ; Fri, 4 Apr 2014 10:58:00 GMT Received: from EXTXIHT04.nam.nsroot.net (EXTXIHT04.nam.nsroot.net [169.177.87.31]) by imbhub-mw34.nam.nsroot.net (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s34Av2tV030974 for ; Fri, 4 Apr 2014 10:57:17 GMT Received: from EXTXRHT04.nam.nsroot.net (169.177.87.33) by EXTXIHT04.nam.nsroot.net (169.177.87.31) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 4 Apr 2014 05:57:07 -0500 Received: from EXTXMB21.nam.nsroot.net ([169.254.6.203]) by EXTXRHT04.nam.nsroot.net ([169.177.87.33]) with mapi id 14.03.0174.001; Fri, 4 Apr 2014 05:57:07 -0500 From: "Poling, Raymond " To: "'user@storm.incubator.apache.org'" Subject: Trouble with Acking After a Worker Fails Thread-Topic: Trouble with Acking After a Worker Fails Thread-Index: Ac9P9J3PcO07neg4RdOWLW8FPvbo1A== Date: Fri, 4 Apr 2014 10:57:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [169.177.87.250] Content-Type: multipart/alternative; boundary="_000_FC0B269FDD2F7A47876B7AAAB6690BA72986C8F8EXTXMB21namnsro_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-04-04_04:2014-04-04,2014-04-04,1970-01-01 signatures=0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_FC0B269FDD2F7A47876B7AAAB6690BA72986C8F8EXTXMB21namnsro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sometimes when we run a three node topology, if a worker fails and comes ba= ck up, the entire topology will become sluggish, and messages will constant= ly be marked as failed. After changing the logging, we can determine that t= he topology is actually fully processing messages, however they are never b= eing passed back to the acker to be acked. I've done searches to try and fi= nd solutions (other than don't let the worker fail) to fix the issue, but h= aven't found anything yet. --_000_FC0B269FDD2F7A47876B7AAAB6690BA72986C8F8EXTXMB21namnsro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sometimes when we run a three node topology, if a wo= rker fails and comes back up, the entire topology will become sluggish, and= messages will constantly be marked as failed. After changing the logging, = we can determine that the topology is actually fully processing messages, however they are never being passed= back to the acker to be acked. I’ve done searches to try and find so= lutions (other than don’t let the worker fail) to fix the issue, but = haven’t found anything yet.

 

--_000_FC0B269FDD2F7A47876B7AAAB6690BA72986C8F8EXTXMB21namnsro_--