Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 19 Aug 2016 04:35:21 +0000 (UTC)
From: "Jeff Jirsa (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12998312.1471554406000.351607.1471581321004@Atlassian.JIRA>
In-Reply-To: <JIRA.12998312.1471554406000@Atlassian.JIRA>
References: <JIRA.12998312.1471554406000@Atlassian.JIRA> <JIRA.12998312.1471554406778@arcas>
Subject: [jira] [Commented] (CASSANDRA-12498) Shorten the sstable log
 message as it unnecessarily contains the full path of a SSTable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 19 Aug 2016 04:35:24 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-12498?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15427610#comment-15427610 ]=20

Jeff Jirsa commented on CASSANDRA-12498:
----------------------------------------

Sort of -0 on this for two reasons:=20

{code}
For JBOD configuration where you have multiple data directories, keeping th=
e one level before ksName/cfName-UUID should be adequat
{code}

In the jbod/multiple data dir case, you may have lots of prefixes with simi=
lar names, ie: {{/mnt1/cassandra/data/ks/tbl}}, {{/mnt2/cassandra/data/ks/t=
bl}}, and so on. It's impossible to predict how users will name/organize th=
eir jbod system, so you'd be trying to guess, and inevitably cause pain for=
 someone.

Also, I suspect that the repetitive log entries are annoying, but they also=
 allow operators to do some intelligent scripting via log parsing that woul=
d be complicated if the prefixes disappear.

> Shorten the sstable log message as it unnecessarily contains the full pat=
h of a SSTable
> -------------------------------------------------------------------------=
--------------
>
>                 Key: CASSANDRA-12498
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1249=
8
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Observability
>            Reporter: Wei Deng
>            Priority: Minor
>
> There are a lot of places in debug.log where we print out the name of a S=
STable. This is useful to look at the full path of a SSTable file when you'=
re investigating individual SSTable. However, during compaction, we often s=
ee 32 SSTables getting compacted at the same time, and the corresponding lo=
g line becomes very repetitive and hard to read as most of them are repeati=
ng the same first part of the file system path again and again, like the fo=
llowing:
> {noformat}
> DEBUG [CompactionExecutor:94] 2016-08-18 06:33:17,185  CompactionTask.jav=
a:146 - Compacting (a5ca2f10-650d-11e6-95ef-a561ab3c45e8) [/var/lib/cassand=
ra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-200-big-Dat=
a.db:level=3D1, /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e=
6a038bfe806276de2/mb-201-big-Data.db:level=3D1, /var/lib/cassandra/data/key=
space1/standard1-139cc441650d11e6a038bfe806276de2/mb-16-big-Data.db:level=
=3D0, /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe80=
6276de2/mb-204-big-Data.db:level=3D1, /var/lib/cassandra/data/keyspace1/sta=
ndard1-139cc441650d11e6a038bfe806276de2/mb-205-big-Data.db:level=3D1, /var/=
lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-=
203-big-Data.db:level=3D1, /var/lib/cassandra/data/keyspace1/standard1-139c=
c441650d11e6a038bfe806276de2/mb-202-big-Data.db:level=3D1, /var/lib/cassand=
ra/data/keyspace1/standard1-139cc441650d11e6a038bfe806276de2/mb-207-big-Dat=
a.db:level=3D1, /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e=
6a038bfe806276de2/mb-206-big-Data.db:level=3D1, /var/lib/cassandra/data/key=
space1/standard1-139cc441650d11e6a038bfe806276de2/mb-3-big-Data.db:level=3D=
0, /var/lib/cassandra/data/keyspace1/standard1-139cc441650d11e6a038bfe80627=
6de2/mb-208-big-Data.db:level=3D1, /var/lib/cassandra/data/keyspace1/standa=
rd1-139cc441650d11e6a038bfe806276de2/mb-209-big-Data.db:level=3D1, ]
> {noformat}
> We should remove any text one level before ksName/cfName-UUID/ as it's ve=
ry easy to get them from cassandra.yaml. For JBOD configuration where you h=
ave multiple data directories, keeping the one level before ksName/cfName-U=
UID should be adequate.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)