Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of JEREMIAH.JORDAN@morningstar.com
 designates 216.228.224.33 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
Subject: Re: How is Cassandra being used?
From: Jeremiah Jordan <jeremiah.jordan@morningstar.com>
In-Reply-To: <0750E56E-AD6E-4852-B5F5-AC3D6966B994@gmail.com>
Date: Wed, 16 Nov 2011 20:41:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDC56E8B-A376-46C7-99EA-32FCE5533318@morningstar.com>
References: 
 <CALdd-zi-MqBzjA4fqBc8y5XANya8F1_rBCR=s49PEGg+Kx6BjA@mail.gmail.com>
 <4EC43FF9.2040405@dehora.net>
 <0750E56E-AD6E-4852-B5F5-AC3D6966B994@gmail.com>
To: dev@cassandra.apache.org

+1 for a separate jar (and a second download link that doesn't include =
this jar, though I would make the primary link include it with BIG BOLD =
PRINT saying it is in there)
+1 for a config option to turn off auto-post (defaulted on in the =
download that has the jar)
+1 for a nodetool command to dump it to a file for manual posting

I think this could be a good debugging tool as well.  Have a command to =
dump "here is what my cluster looks like" to a file, that could then be =
sent though email for others to be used help resolve issues with would =
be nice.  The current nodetool information commands have too much stuff =
that needs to be sanitized out before you can send it outside the =
firewall.

- Jeremiah

On Nov 16, 2011, at 7:16 PM, Jeremy Hanna wrote:

> Sounds like it would be best if it were in a separate jar for people?
>=20
> On Nov 16, 2011, at 4:58 PM, Bill wrote:
>=20
>>> Thoughts?
>>>=20
>>=20
>> We'll turn this off, and would possibly patch it out of the code. =
That's not to say it wouldn't be useful to others.
>>=20
>> Bill
>>=20
>>=20
>> On 15/11/11 23:23, Jonathan Ellis wrote:
>>> I started a "users survey" thread over on the users list (replies =
are
>>> still trickling in), but as useful as that is, I'd like to get
>>> feedback that is more quantitative and with a broader base.  This =
will
>>> let us prioritize our development efforts to better address what
>>> people are actually using it for, with less guesswork.  For =
instance:
>>> we put a lot of effort into compression for 1.0.0; if it turned out
>>> that only 1% of 1.0.x users actually enable compression, then it =
means
>>> that we should spend less effort fine-tuning that moving forward, =
and
>>> use the energy elsewhere.
>>>=20
>>> (Of course it could also mean that we did a terrible job getting the
>>> word out about new features and explaining how to use them, but =
either
>>> way, it would be good to know!)
>>>=20
>>> I propose adding a basic cluster reporting feature to =
cassandra.yaml,
>>> enabled by default.  It would send anonymous information about your
>>> cluster to an apache.org VM.  Information like, number (but not =
names)
>>> of keyspaces and columnfamilies, ks-level options like compression, =
cf
>>> options like compaction strategy, data types (again, not names) of
>>> columns, average row size (or better: the histogram data), and =
average
>>> sstables per read.
>>>=20
>>> Thoughts?
>>>=20
>>=20
>>=20
>=20