[ 
https://issues.apache.org/jira/browse/HADOOP-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521511
 ] 

Jim Kellerman commented on HADOOP-1724:
---------------------------------------

Looking at the (non-deprecated) methods in HRegionInterface, there are two that 
could return a status: batchUpdate and close (a scanner).

However, the remainder return a value.

The Java paradigm seems (to me at least) to be that methods return values or 
void and not a status code. Errors are handled by throwing exceptions. This is 
the paradigm that is followed by the other Hadoop RPC protocols.

A client sending a request to the wrong server, either due to a bug or because 
the region has moved to another server feels like an error to me, and throwing 
an exception to get the client to 'recalibrate' seems ok.

The server really has no other choice because input parameters are final (any 
modification to them are not returned to the client).

The only other thing we could do is wrap each returned value in another 
Writable which always contains a "status message". This does not feel like the 
right paradigm to me.

The only other solution I can think of is to make two RPCs for every one we 
make today. The first asks the server, "Are you serving this region?", and 
based on that answer either sends the "real" message or "recalibrates". Seems 
highly inefficient to me.

If there are other ideas I have overlooked, please comment here.

> [hbase] 'Normal' operation should not depend on throwing of exceptions (e.g. 
> NotServingRegionException)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-1724
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1724
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: contrib/hbase
>            Reporter: stack
>            Assignee: Jim Kellerman
>            Priority: Minor
>
> Region server and client logs will have lots of the following when a cluster 
> is being loaded:
> {code}
> org.apache.hadoop.hbase.NotServingRegionException: 
> hbaserepository,,7144829661993961256
>         at 
> org.apache.hadoop.hbase.HRegionServer.getRegion(HRegionServer.java:1208)
>         at 
> org.apache.hadoop.hbase.HRegionServer.getRegion(HRegionServer.java:1180)
>         at 
> org.apache.hadoop.hbase.HRegionServer.startUpdate(HRegionServer.java:1122)
>         at 
> org.apache.hadoop.hbase.HRegionServer.batchUpdate(HRegionServer.java:985)
>         at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:340)
>         at org.apache.hadoop.ipc.Server$Handler.run(Server.java:566)
> {code}
> The NotServingRegionException exception is thrown when the remote server is 
> no longer serving the asked-for region (usually because its been split).  The 
> server throws the exception to provoke the client into making a new 
> interrogation of region locations.
> It would be an improvement if such 'normal' operation was not built atop 
> exceptions.  For example, commits might return a 'region moved' message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to