cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-3142) CustomTThreadPoolServer should log TTransportException at DEBUG level
Date Tue, 06 Sep 2011 17:57:10 GMT


Jonathan Ellis updated CASSANDRA-3142:

         Reviewer: xedin
         Priority: Minor  (was: Major)
    Fix Version/s: 0.8.6
         Assignee: Jim Ancona

> CustomTThreadPoolServer should log TTransportException at DEBUG level
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-3142
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jim Ancona
>            Assignee: Jim Ancona
>            Priority: Minor
>             Fix For: 0.8.6
>         Attachments: v1-0001-CASSANDRA-3142-Add-debug-level-logging-of-TTransportEx.txt
> Currently CustomTThreadPoolServer, like the Thrift TThreadPoolServer, silently ignores
TTransportException in its run() method. This is appropriate in most cases because TTransportException
occurs fairly often when client connections die. However TTransportException is also thrown
when TFramedTransport encounters a frame that is larger than thrift_framed_transport_size_in_mb.
In that case, silently exiting the run loop leads to a SocketException on the client side
which can be both difficult to diagnose, in part because nothing is logged by Cassandra, and
high-impact, because the client may respond by marking the server node down and retrying the
too-large request on another node, where it also fails. This process repeated leads to the
entire cluster being marked down (see I've filed
two Thrift issues ( and,
but in the meantime, I suggest that CustomTThreadPoolServer log the exception at DEBUG level
in order to support easier troubleshooting.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message