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

Veena Basavaraj edited comment on SQOOP-1784 at 11/23/14 11:04 PM:
-------------------------------------------------------------------

I just checked the head of SQOOP2 and realized the integration tests do fail 
after SQOOP-1775 commit. And then realized why the commit happened even tests 
failed.
{code}
 <testcase time="9.101" 
classname="org.apache.sqoop.integration.connector.jdbc.generic.FromHDFSToRDBMSTest"
 name="testBasic">
    <error message="CLIENT_0001:Server has returned exception" 
type="org.apache.sqoop.common.SqoopException">org.apache.sqoop.common.SqoopException:
 CLIENT_0001:Server has returned exception
        at 
org.apache.sqoop.client.request.ResourceRequest.doHttpRequest(ResourceRequest.java:113)
        at 
org.apache.sqoop.client.request.ResourceRequest.post(ResourceRequest.java:148)
        at 
org.apache.sqoop.client.request.LinkResourceRequest.create(LinkResourceRequest.java:59)
        at 
org.apache.sqoop.client.request.SqoopResourceRequests.saveLink(SqoopResourceRequests.java:96)
        at org.apache.sqoop.client.SqoopClient.saveLink(SqoopClient.java:326)
        at 
org.apache.sqoop.test.testcases.ConnectorTestCase.saveLink(ConnectorTestCase.java:222)
        at 
org.apache.sqoop.integration.connector.jdbc.generic.FromHDFSToRDBMSTest.testBasic(FromHDFSToRDBMSTest.java:48)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
        at org.junit.rules.RunRules.evaluate(RunRules.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
        at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
        at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
        at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
        at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
        at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.NullPointerException:
        at org.apache.sqoop.json.LinkBean.restore(LinkBean.java:124)
        at 
org.apache.sqoop.handler.LinkRequestHandler.createUpdateLink(LinkRequestHandler.java:115)
        at 
org.apache.sqoop.handler.LinkRequestHandler.handleEvent(LinkRequestHandler.java:66)
        at 
org.apache.sqoop.server.v1.LinkServlet.handlePostRequest(LinkServlet.java:72)

{code}



Better late than never for https://issues.apache.org/jira/browse/SQOOP-1777, 
appreciate making this change.


was (Author: vybs):
I just checked the head of SQOOP2 and realized the integration tests do fail 
after SQOOP-1775 commit. And then realized why the commit happened even tests 
failed.



Better late than never for https://issues.apache.org/jira/browse/SQOOP-1777, 
appreciate making this change.

> Sqoop2: Sending POST request to link or job end-point might end up with NPE
> ---------------------------------------------------------------------------
>
>                 Key: SQOOP-1784
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1784
>             Project: Sqoop
>          Issue Type: Bug
>    Affects Versions: 1.99.4
>            Reporter: Jarek Jarcec Cecho
>            Assignee: Jarek Jarcec Cecho
>             Fix For: 1.99.5
>
>         Attachments: SQOOP-1784.patch
>
>
> I was testing few patches on real cluster and noticed that creating link on 
> current head of {{sqoop2}} branch can lead to NPE in {{LinkBean}}. I've 
> traced the code and found out that 
> {{[ctx.getRequest().getReader()|https://github.com/apache/sqoop/blob/sqoop2/server/src/main/java/org/apache/sqoop/handler/LinkRequestHandler.java#L114]}}
>  is returning empty buffer and as a result the subsequent call to 
> {{JSONValue.parse}} returns {{null}} and we hit {{NullPointerException}} 
> later in {{LInkBean}}.
> This one was quite hard to crack, but I believe that I've isolated the 
> problem. In SQOOP-1774 we've changed the way to get username from header to 
> URL parameter and we're using 
> {{[ServletRequest.getParameter()|https://github.com/apache/sqoop/blob/sqoop2/server/src/main/java/org/apache/sqoop/server/RequestContext.java#L121]}}
>  method for that. Carefully reading it's 
> [javadoc|https://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getParameter(java.lang.String)]
>  I found out that:
> {quote}
> If the parameter data was sent in the request body, such as occurs with an 
> HTTP POST request, then reading the body directly via getInputStream() or 
> getReader() can interfere with the execution of this method
> {quote}
> And hence I'm assuming that getting the username has processed the request 
> body already and thus we got the eventual {{NullPointerException}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to