[ 
https://issues.apache.org/jira/browse/CASSANDRA-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14506005#comment-14506005
 ] 

Benedict commented on CASSANDRA-9084:
-------------------------------------

The results of a quick hacky script to tell us which duplicate log messages 
there are:

{noformat}
Validating {}
        RepairJob.java:212
        RepairJob.java:225
        RepairJob.java:266
        RepairJob.java:279
Failed to set keep-alive on Thrift socket.
        TCustomNonblockingServerSocket.java:58
        TCustomServerSocket.java:117
Could not configure socket.
        TCustomSocket.java:75
        TCustomSocket.java:125
adding secondary index {} to operation
        Keyspace.java:446
        Keyspace.java:491
skipping {}
        KeysSearcher.java:159
        CompositesSearcher.java:206
Write timeout; received {} of {} required replies
        StorageProxy.java:574
        StorageProxy.java:690
Exception in thread {}
        CassandraDaemon.java:234
        CassandraDaemon.java:235
        CassandraDaemon.java:243
Skipping {}
        KeysSearcher.java:143
        CompositesSearcher.java:196
Loading {}
        Schema.java:472
        Schema.java:524
        Schema.java:555
        Schema.java:583
[repair #{}] {}
        RepairSession.java:176
        RepairSession.java:230
        RepairSession.java:243
        RepairSession.java:266
        RepairJob.java:187
        RemoteSyncTask.java:54
        LocalSyncTask.java:67
        LocalSyncTask.java:107
Notified {}
        Gossiper.java:966
        Gossiper.java:980
Read only {} (< {}) last page through, must be done
        KeysSearcher.java:110
        CompositesSearcher.java:167
Sleeping for {}ms to ensure {} does not change
        Gossiper.java:515
        Gossiper.java:591
JVM doesn't support Adler32 byte buffer access
        FBUtilities.java:640
        FBUtilities.java:672
DiskAccessMode is {}, indexAccessMode is {}
        DatabaseDescriptor.java:315
        DatabaseDescriptor.java:320
Enqueuing response to {}
        RangeSliceVerbHandler.java:37
        MutationVerbHandler.java:52
        ReadVerbHandler.java:43
Drop {}
        Schema.java:573
        Schema.java:601
Updating {}
        Schema.java:536
        Schema.java:564
        Schema.java:592
Could not initialize SIGAR library {} 
        SigarLibrary.java:51
        SigarLibrary.java:55
Empty output skipped, filter empty tuples to suppress this warning
        CassandraStorage.java:511
        CqlNativeStorage.java:396
Acquiring sstable references
        CollationController.java:77
        CollationController.java:204
Index build of {} complete
        SecondaryIndexManager.java:170
        SecondaryIndex.java:222
Miscellaneous task executor still busy after one minute; proceeding with 
shutdown
        StorageService.java:661
        StorageService.java:3827
Failed to set receive buffer size on Thrift socket.
        TCustomNonblockingServerSocket.java:81
        TCustomServerSocket.java:140
Snapshot-based repair is not yet supported on Windows.  Reverting to parallel 
repair.
        StorageService.java:2793
        StorageService.java:2861
Failed to set send buffer size on Thrift socket.
        TCustomNonblockingServerSocket.java:69
        TCustomServerSocket.java:128
{} found, but does not look like a plain file. Will not watch it for changes
        GossipingPropertyFileSnitch.java:92
        PropertyFileSnitch.java:79
Opening {} ({} bytes)
        SSTableReader.java:384
        SSTableReader.java:430
Some replicas have already promised a higher ballot than ours; aborting
        StorageProxy.java:376
        StorageProxy.java:410
Corrupt sstable {}; skipped
        SSTableReader.java:454
        SSTableReader.java:477
Could not set socket timeout.
        TCustomSocket.java:139
        TCustomServerSocket.java:159
Compaction executor has shut down, not submitting task
        CompactionManager.java:533
        CompactionManager.java:603
Cannot start multiple repair sessions over the same sstables
        RepairMessageVerbHandler.java:100
        CompactionManager.java:1033
Scanning index {} starting with {}
        KeysSearcher.java:115
        CompositesSearcher.java:172
Executor has shut down, not submitting background task
        CompactionManager.java:183
        CompactionManager.java:1294
Reached end of assigned scan range
        KeysSearcher.java:166
        CompositesSearcher.java:238
Unavailable
        StorageProxy.java:582
        StorageProxy.java:684
error registering MBean {}
        CassandraDaemon.java:551
        BlacklistedDirectories.java:54
{noformat}


I don't have a super strong opinion either way, but I do dislike adding line 
numbers when they're mostly redundant. I am mostly certain under current 
default scenarios it has zero performance impact, but it does leave open a 
window for performance regressions if logging happens on any critical paths 
without realisation, and on enabling debug/trace logging it very likely does 
already, so having the defaults configured not to upset cluster behaviour too 
much when enabling this is a positive. But, like I say, my position is very 
weakly held.

> Do not generate line number in logs
> -----------------------------------
>
>                 Key: CASSANDRA-9084
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9084
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Config
>            Reporter: Andrey
>            Assignee: Benedict
>            Priority: Minor
>
> According to logback documentation 
> (http://logback.qos.ch/manual/layouts.html):
> {code}
> Generating the line number information is not particularly fast. Thus, its 
> use should be avoided unless execution speed is not an issue.
> {code}



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

Reply via email to