[ 
https://issues.apache.org/jira/browse/PHOENIX-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939993#comment-13939993
 ] 

James Taylor edited comment on PHOENIX-875 at 3/19/14 12:05 AM:
----------------------------------------------------------------

Do you have a way of reproducing this? The stack trace indicates a problem 
during dropTable, but your change to loadTable wouldn't get used because 
dropTable never calls loadTable. The callers to loadTable all deal fine with a 
return of the table delete marker.

I suspect doDropTable is hitting this else block when the table is deleted:
{code}
            } else {
                return new 
MetaDataMutationResult(MutationCode.NEWER_TABLE_FOUND,
                        EnvironmentEdgeManager.currentTimeMillis(), table);
            }
{code}
and then the PTableImpl.toProto is blowing up because our table delete marker 
isn't meant to be serialized (it doesn't set everything that's expected).

I believe if we change that else block to just set the table parameter to null 
instead, we should be ok, as the client caller doesn't ever require table to be 
set when a NEWER_TABLE_FOUND code is returned, like this:
{code}
            } else {
                return new 
MetaDataMutationResult(MutationCode.NEWER_TABLE_FOUND,
                        EnvironmentEdgeManager.currentTimeMillis(), null);
            }
{code}

Can you try this and see if the problem goes away?


was (Author: jamestaylor):
Do you have a way of reproducing this? The stack trace indicates a problem 
during dropTable, but your change to loadTable wouldn't get used because 
dropTable never calls loadTable. The callers to loadTable all deal fine with a 
return of the table delete marker.

I suspect doDropTable is hitting this else block when the table is deleted:
{code}
            } else {
                return new 
MetaDataMutationResult(MutationCode.NEWER_TABLE_FOUND,
                        EnvironmentEdgeManager.currentTimeMillis(), table);
            }
{code}
and then the PTableImpl.toProto is blowing up because our table delete marker 
isn't meant to be serialized (it doesn't set everything that's expected).

I believe if we change that else block to just set the table parameter to null 
instead, we should be ok, as the client caller doesn't ever require table to be 
set when a NEWER_TABLE_FOUND code is returned, like this:
{code}
            } else {
                return new 
MetaDataMutationResult(MutationCode.NEWER_TABLE_FOUND,
                        EnvironmentEdgeManager.currentTimeMillis(), table);
            }
{code}

Can you try this and see if the problem goes away?

> NPE when running end2end tests against a live cluster
> -----------------------------------------------------
>
>                 Key: PHOENIX-875
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-875
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Jeffrey Zhong
>            Assignee: Jeffrey Zhong
>         Attachments: phoenix-875.patch
>
>
> Below is the error stack trace. The cause is that 
> MetaDataEndpointImpl#loadTable doesn't check if a table is a deleted marker 
> after the line {code}PTable table = 
> metaDataCache.getIfPresent(cacheKey);{code}.
> {code}
> 2014-03-18 10:54:06,633 ERROR [RpcServer.handler=8,port=60020] 
> coprocessor.MetaDataEndpointImpl: dropTable failed
> java.lang.NullPointerException
>         at org.apache.phoenix.schema.PTableImpl.toProto(PTableImpl.java:892)
>         at 
> org.apache.phoenix.coprocessor.MetaDataProtocol$MetaDataMutationResult.toProto(MetaDataProtocol.java:184)
>         at 
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:934)
>         at 
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:6565)
>         at 
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5489)
>         at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3297)
>         at 
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:28865)
>         at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2008)
>         at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:92)
>         at 
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>         at 
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>         at 
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>         at java.lang.Thread.run(Thread.java:722)
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to