[
https://issues.apache.org/jira/browse/THRIFT-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098515#comment-13098515
]
Jim Ancona commented on THRIFT-1323:
------------------------------------
That's right, this is using Java for both client and server. I think either a
subclass or a specific TTransportException.type_ would be fine. When I added
logging to Cassandra in place of the swallowed exception, I saw quite a few
logged. But I think logging at DEBUG level is appropriate, and I've created an
issue and patch for Cassandra to do that in its CustomTThreadPoolServer. If you
can distinguish between frame to large and other TTransportExceptions, I would
suggest INFO or WARNING for the frame too large case.
> 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
