[
https://issues.apache.org/jira/browse/CASSANDRA-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: https://issues.apache.org/jira/browse/CASSANDRA-3142
> 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
> https://github.com/rantav/hector/issues/212). I've filed two Thrift issues
> (https://issues.apache.org/jira/browse/THRIFT-1323 and
> https://issues.apache.org/jira/browse/THRIFT-1324), 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: http://www.atlassian.com/software/jira
