Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B1F259D83 for ; Fri, 17 Feb 2012 17:36:37 +0000 (UTC) Received: (qmail 15406 invoked by uid 500); 17 Feb 2012 17:36:35 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 15387 invoked by uid 500); 17 Feb 2012 17:36:35 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 15378 invoked by uid 99); 17 Feb 2012 17:36:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 17:36:35 +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 (athena.apache.org: domain of mor.yuki@gmail.com designates 209.85.160.172 as permitted sender) Received: from [209.85.160.172] (HELO mail-gy0-f172.google.com) (209.85.160.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 17:36:27 +0000 Received: by ghbg16 with SMTP id g16so2211515ghb.31 for ; Fri, 17 Feb 2012 09:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=EZs6YhdBlC5X0aOJriJ/e1Fnr+nr92gr0wArRlA/wXo=; b=f/oVOf82fdzR6ljZdngN+DbfqBMhVe1ubLvsfP1piiagfcKAiOBIC4PhEK/X7s9d3j 44zVVWxK9h0scZEWmZjtkMntgAulaD2npocVf+NX6u5z8BRWoAmd+7NfC4Thz8F5seSp Luajkicbzig21kGdHm92l5eCihbU42SwNp194= Received: by 10.236.178.72 with SMTP id e48mr10685140yhm.28.1329500166929; Fri, 17 Feb 2012 09:36:06 -0800 (PST) Received: from valkyrie.local (66-90-218-157.dyn.grandenetworks.net. [66.90.218.157]) by mx.google.com with ESMTPS id g49sm23993348yhk.20.2012.02.17.09.36.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 09:36:06 -0800 (PST) Date: Fri, 17 Feb 2012 11:36:03 -0600 From: Yuki Morishita To: user@cassandra.apache.org Message-ID: In-Reply-To: <4F3E45A1.3020801@opera.com> References: <4F3E45A1.3020801@opera.com> Subject: Re: Streaming sessions from BulkOutputFormat job being listed long after they were killed X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f3e9003_520eedd1_cc" --4f3e9003_520eedd1_cc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Erik, Currently, streaming failure handling is poorly functioning. There are several discussions and bug reports regarding streaming failure on jira. Hanged streaming session will be left in memory unless you restart C*, but it does not cause problem I believe. -- Yuki Morishita On Friday, February 17, 2012 at 6:18 AM, Erik Forsberg wrote: > Hi! > > If I run a hadoop job that uses BulkOutputFormat to write data to > Cassandra, and that hadoop job is aborted, i.e. streaming sessions are > not completed, it seems like the streaming sessions hang around for a > very long time, I've observed at least 12-15h, in output from 'nodetool > netstats'. > > To me it seems like they go away only after a restart of Cassandra. > > Is this a known behaviour? Does it cause any problems, f. ex. consuming > memory, or should I just ignore it? > > Regards, > \EF > > --4f3e9003_520eedd1_cc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Erik,

Currently, streaming f= ailure handling is poorly functioning. 
There are several = discussions and bug reports regarding streaming failure on jira.

Hanged streaming session will be left in memory unless y= ou restart C*, but it does not cause problem I believe.

-- 
Yuki Morishit= a

=20

On =46riday, =46ebruar= y 17, 2012 at 6:18 AM, Erik =46orsberg wrote:

Hi=21

I= f I run a hadoop job that uses BulkOutput=46ormat to write data to
=
Cassandra, and that hadoop job is aborted, i.e. streaming sessions a= re
not completed, it seems like the streaming sessions hang ar= ound for a
very long time, I've observed at least 12-15h, in o= utput from 'nodetool
netstats'.

To me= it seems like they go away only after a restart of Cassandra.
=
Is this a known behaviour=3F Does it cause any problems, f= . ex. consuming
memory, or should I just ignore it=3F

Regards,
=5CE=46
=20 =20 =20 =20
=20

--4f3e9003_520eedd1_cc--