cassandra-commits mailing list archives

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


Jim Ancona updated CASSANDRA-3142:

    Attachment: v1-0001-CASSANDRA-3142-Add-debug-level-logging-of-TTransportEx.txt

> CustomTThreadPoolServer should log TTransportException at DEBUG level
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-3142
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jim Ancona
>         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.
> I can submit a patch with the added log message.

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


View raw message