[
https://issues.apache.org/jira/browse/HBASE-12334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182371#comment-14182371
]
James Taylor commented on HBASE-12334:
--------------------------------------
Not sure which one you want - I'm tracing it in a debugger. There's enough
throwing and catching there to make the Giants proud! :-)
Here's a few of them:
{code}
Daemon Thread [defaultRpcServer.handler=4,queue=0,port=50594] (Suspended)
ProtobufUtil.toFilter(FilterProtos$Filter) line: 1362
FilterList.parseFrom(byte[]) line: 403
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ProtobufUtil.toFilter(FilterProtos$Filter) line: 1360
ProtobufUtil.toScan(ClientProtos$Scan) line: 917
MiniHBaseCluster$MiniHBaseClusterRegionServer(HRegionServer).scan(RpcController,
ClientProtos$ScanRequest) line: 3078
ClientProtos$ClientService$2.callBlockingMethod(Descriptors$MethodDescriptor,
RpcController, Message) line: 29497
RpcServer.call(BlockingService, MethodDescriptor, Message, CellScanner,
long, MonitoredRPCHandler) line: 2027
CallRunner.run() line: 98
{code}
and then this:
{code}
Daemon Thread [defaultRpcServer.handler=4,queue=0,port=50594] (Suspended)
FilterList.parseFrom(byte[]) line: 406
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ProtobufUtil.toFilter(FilterProtos$Filter) line: 1360
ProtobufUtil.toScan(ClientProtos$Scan) line: 917
MiniHBaseCluster$MiniHBaseClusterRegionServer(HRegionServer).scan(RpcController,
ClientProtos$ScanRequest) line: 3078
ClientProtos$ClientService$2.callBlockingMethod(Descriptors$MethodDescriptor,
RpcController, Message) line: 29497
RpcServer.call(BlockingService, MethodDescriptor, Message, CellScanner,
long, MonitoredRPCHandler) line: 2027
CallRunner.run() line: 98
{code}
and finally this:
{code}
Daemon Thread [defaultRpcServer.handler=4,queue=0,port=50594] (Suspended)
MiniHBaseCluster$MiniHBaseClusterRegionServer(HRegionServer).scan(RpcController,
ClientProtos$ScanRequest) line: 3239
ClientProtos$ClientService$2.callBlockingMethod(Descriptors$MethodDescriptor,
RpcController, Message) line: 29497
RpcServer.call(BlockingService, MethodDescriptor, Message, CellScanner,
long, MonitoredRPCHandler) line: 2027
CallRunner.run() line: 98
{code}
> Handling of DeserializationException causes needless retry on failure
> ---------------------------------------------------------------------
>
> Key: HBASE-12334
> URL: https://issues.apache.org/jira/browse/HBASE-12334
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.7
> Reporter: James Taylor
> Labels: Phoenix
>
> If an unexpected exception occurs when deserialization occurs for a custom
> filter, the exception gets wrapped in a DeserializationException. Since this
> exception is in turn wrapped in an IOException, the many loop retry logic
> kicks in. The net effect is that this same deserialization error occurs again
> and again as the retries occur, just causing the client to wait needlessly.
> IMO, either the parseFrom methods should be allowed to throw whatever type of
> IOException they'd like, in which case they could throw a
> DoNotRetryIOException, or a DeserializationException should be wrapped in a
> DoNotRetryIOException.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
