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 67641514F for ; Fri, 13 May 2011 01:39:49 +0000 (UTC) Received: (qmail 91473 invoked by uid 500); 13 May 2011 01:39:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 91440 invoked by uid 500); 13 May 2011 01:39:47 -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 91432 invoked by uid 99); 13 May 2011 01:39:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 May 2011 01:39:47 +0000 X-ASF-Spam-Status: No, hits=3.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xiaowei609@gmail.com designates 209.85.215.172 as permitted sender) Received: from [209.85.215.172] (HELO mail-ey0-f172.google.com) (209.85.215.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 May 2011 01:39:40 +0000 Received: by eye13 with SMTP id 13so740241eye.31 for ; Thu, 12 May 2011 18:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Onyjxd58T1P2u6+nMGQx7ZYM9frNurukRbyKZpgVGOk=; b=nnD9HWqxkz3oXUjYdI/ebtwv2GVasJn+oN3HNHxISqsTwgk452P8eZOnBrO5Pov2nb BZZJjgeN5HxkfA9Ur44HALFKzBaYNwj9Zs0lKbTvHkBgCrngrbolpwMuzEwdwFI6NXLA IVvd+0HOjehuqoTl7fHh3g6+VIbWPfyZMZp2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=i6fMHhNQtYC/a0ydn/GWZsoG+GcU2HEvpzWpOsv3A6b9piQMdNcLGAOseV0ggi+qSO WIbakdg1n7p0kO9qudIqQ5QFOHtNzCZe0wmoEFaRqou2qJSfgZf5ATIF6jvDVZBiJ5/M ovsptYCE+vfLImo2XNN/cMhimCTamyGOkp6V0= MIME-Version: 1.0 Received: by 10.213.2.132 with SMTP id 4mr484410ebj.44.1305250758882; Thu, 12 May 2011 18:39:18 -0700 (PDT) Received: by 10.213.10.131 with HTTP; Thu, 12 May 2011 18:39:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2011 21:39:18 -0400 Message-ID: Subject: Re: running TPC-C on cassandra clusters From: Xiaowei Wang To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0015174be054d3763a04a31e5fc8 X-Virus-Checked: Checked by ClamAV on apache.org --0015174be054d3763a04a31e5fc8 Content-Type: text/plain; charset=ISO-8859-1 Oh sorry, we use cassandra-0.7.4 already. Is the version fine? 2011/5/12 Jonathan Ellis > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7 > > On Thu, May 12, 2011 at 8:33 PM, Xiaowei Wang > wrote: > > Thanks Jonathan, but can you provide some links about 0.7 svn branch? > > > > 2011/5/12 Jonathan Ellis > >> > >> I'd recommend trying the 0.7 svn branch (soon to be voted on as 0.7.6) > >> > >> On Thu, May 12, 2011 at 3:09 PM, Xiaowei Wang > >> wrote: > >> > Hi all, > >> > > >> > My partner and I currently using cassandra cluster to run TPC-C. We > >> > first > >> > use 2 ec2 nodes to load 20 warehouses. One(client node) has 8 cores, > >> > the > >> > other(worker node) has 4 cores. During the loading time, either the > >> > client > >> > node or the worker node will "down"(cannot be detected) randomly and > >> > then > >> > "up" again in a short time. If the two nodes both down, we failed in > >> > loading. If only one of them down, we can continue to load data. > >> > > >> > The problem is if we use multiple threads(we write multiprocess code), > >> > say 4 > >> > clients threads, some of them might be stop at the point one of the > >> > nodes > >> > first down, and the dead threads will never come back.... This will > not > >> > only > >> > enlarge our loading time, but also effect the amount of data we can > >> > load. > >> > > >> > So we need to figure out why the nodes continue to be up and down and > >> > fix > >> > this problem. > >> > > >> > Thanks for any help! > >> > > >> > Best, > >> > Xiaowei > >> > > >> > > >> > >> > >> > >> -- > >> Jonathan Ellis > >> Project Chair, Apache Cassandra > >> co-founder of DataStax, the source for professional Cassandra support > >> http://www.datastax.com > > > > > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com > --0015174be054d3763a04a31e5fc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh sorry, we use cassandra-0.7.4 already. Is the version fine?

2011/5/12 Jonathan Ellis <jbellis@gmail.com>
https://svn.apache.org/repos/asf/cassandra/branches/ca= ssandra-0.7

On Thu, May 12, 2011 at 8:33 PM, Xiaowei Wang <xiaowei609@gmail.com> wrote:
> Thanks Jonathan, but can you provide some links about 0.7 svn branch?<= br> >
> 2011/5/12 Jonathan Ellis <jbel= lis@gmail.com>
>>
>> I'd recommend trying the 0.7 svn branch (soon to be voted on a= s 0.7.6)
>>
>> On Thu, May 12, 2011 at 3:09 PM, Xiaowei Wang <xiaowei609@gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > My partner and I currently using cassandra cluster to run TPC= -C. We
>> > first
>> > use 2 ec2 nodes to load 20 warehouses. One(client node)=A0 ha= s 8 cores,
>> > the
>> > other(worker node) has 4 cores. During the loading time, eith= er the
>> > client
>> > node or the worker node will "down"(cannot be detec= ted) randomly and
>> > then
>> > "up" again in a short time. If the two nodes both d= own, we failed in
>> > loading. If only one of them down, we can continue to load da= ta.
>> >
>> > The problem is if we use multiple threads(we write multiproce= ss code),
>> > say 4
>> > clients threads, some of them might be stop at the point one = of the
>> > nodes
>> > first down, and the dead threads will never come back.... Thi= s will not
>> > only
>> > enlarge our loading time, but also effect the amount of data = we can
>> > load.
>> >
>> > So we need to figure out why the nodes continue to be up and = down and
>> > fix
>> > this problem.
>> >
>> > Thanks for any help!
>> >
>> > Best,
>> > Xiaowei
>> >
>> >
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra supp= ort
>> http://www.d= atastax.com
>
>



--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.c= om

--0015174be054d3763a04a31e5fc8--