[
https://issues.apache.org/jira/browse/THRIFT-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098422#comment-13098422
]
Bryan Duxbury commented on THRIFT-1323:
---------------------------------------
I think it would be hard to make this any other exception than a
TTransportException, though we could make a subclass if that would be more
helpful. As far as just swallowing the exception, I guess that's really up to
the implementing server. You could make the argument that you should never
swallow an exception. I would commit a patch that unconditionally logged all
exceptions, especially if it was at a log level that was easier to silence if
the messages were too superfluous.
> TFramedTransport should throw an exception that distinguishes an oversized
> frame from a dead client, servers should log that exception
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-1323
> URL: https://issues.apache.org/jira/browse/THRIFT-1323
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
> Reporter: Jim Ancona
>
> When TFramedTransport receives a frame that is larger than the maximum frame
> size, it throws a TTransportException. This makes that error
> indistinguishable from a failed client. Because such errors are common, many
> servers (TSimpleServer, TThreadPoolServer, and Cassandra's
> CustomTThreadPoolServer) swallow TTransportException without a log message,
> making it difficult to diagnose this problem. I'm not familiar enough with
> the code base to suggest which exception to throw in its place, although a
> subclass of TTransportException, or a new TTransportException.type_ value
> might work. In any case, the corresponding server implementations should log
> that condition when it occurs.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
