[ 
https://issues.apache.org/jira/browse/HTTPCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934265#action_12934265
 ] 

Oleg Kalnichevski commented on HTTPCORE-242:
--------------------------------------------

Hi Michael

(1) I did not quite realise that the reproducer for the problem involved NTLM 
authentication. I do not have access to a Windows system with IIS/7.5. So, we 
have to figure something out. One possibility would be to use logging 
decorators from the contrib package to produce a wire log of the HTTP session 
that exhibits the problem [1].

(2) You idea to ensure that request and response processing is serialised makes 
good sense. However, I suspect that in some cases if the request entity is very 
large this may lead to a deadlock, as the client will not be able to react to 
an out of sequence response until the entire request body is written out. I 
suggest that we apply your patch as the first step and then try to find out a 
more comprehensive solution to the problem. Would it be a big deal for you to 
submit the changes in the udiff format by running svn diff on your local 
snapshot of HttpCore?

Oleg

PS: there is an early development version of async HTTP client based on 
HttpCore NIO [2]. You might want to consider contributing some of your code to 
the project if you feel like getting involved.

[1] 
http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-contrib/src/main/java/org/apache/http/contrib/logging/
[2] http://svn.apache.org/repos/asf/httpcomponents/httpasyncclient/trunk/

> NullPointerException in AsyncNHttpClientHandler  when server sends reply 
> before request is fully written.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-242
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-242
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.1
>         Environment: Server:  IIS/7.5 with NTLM authentication.
>            Reporter: Michael Poindexter
>         Attachments: httpcore-connection-reuse-bug.zip
>
>
> I'm seeing a problem with AsyncNHttpClientHandler in v4.1 of HttpCore.  When 
> I submit a number of requests simultaneously or a single POST with a large 
> body to a server using NTLM authentication, I get this exception:
> Caused by: java.lang.NullPointerException
> at 
> org.apache.http.nio.protocol.AsyncNHttpClientHandler.outputReady(AsyncNHttpClientHandler.java:268)
> at 
> org.apache.http.nio.protocol.BufferingHttpClientHandler.outputReady(BufferingHttpClientHandler.java:118)
> at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.produceOutput(DefaultNHttpClientConnection.java:207)
> at 
> org.apache.http.impl.nio.ssl.SSLClientIOEventDispatch.outputReady(SSLClientIOEventDispatch.java:245)
> at 
> com.qumu.cxf.rt.transport.ahttp.MultiProtocolIOEventDispatch.outputReady(MultiProtocolIOEventDispatch.java:49)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:185)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:275)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
> at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:542)
> at java.lang.Thread.run(Thread.java:680)
> The server I am connecting to is IIS/7.5. I am using NTLM authentication 
> (with JCIFS), so I need to keep the connection alive through several round 
> trips as the NTLM message exchange occurs.
> I dug into the HttpCore code, and here is my analysis of what is occurring:
> 1.) AsyncNHttpClientHandler.connect calls requestReady to send the initial 
> request.  This sets the request on the connection, and the connection starts 
> writing the request line in response to write events.
> 2.) The server receives the request line and responds immediately with a 401 
> Unauthorized.  At this point the POST body has not been fully sent to the 
> server.
> 3.) AsyncNHttpClientHandler.inputReady is called with the response from the 
> server.  At this point processResponse is called, and my code executes.  I 
> detect that the request needs authentication and I need to retransmit my 
> request with an auth header, so my ConnectionReuseStrategy says to keep the 
> connection alive.
> 4.) When control returns from my code, the code in processResponse calls 
> connState.resetOutput, clearing the entity and request in connState.  There 
> is still output from the POST body pending.
> 5.)  processResponse calls conn.requestOutput to reenable write events since 
> the connection is not to be closed.
> 6.)  A write event happens, and DefaultNHttpClientConnection.produceOutput is 
> called.  Since the output from the initial request never finished, 
> contentEncoder is not null and so AsyncNHttpClientHandler.outputReady is 
> called instead of requestReady.  Since connState was reset, the entity is 
> null and this NPE happens.
> I copied the code of AsyncNHttpClientHandler and added a conn.suspendInput() 
> call in requestReady:
>            if (entityReq != null && entityReq.expectContinue()) {
>                .....
>            } else {
>            conn.suspendInput();
>            }
> and a conn.requestInput call in outputReady:
>            entity.produceContent(encoder, conn);
>            if(encoder.isCompleted()) {
>            conn.requestInput();
>            }
> and this seemed to resolve the issue by not allowing the request and response 
> to overlap, but I'm not sure this is the best way to fix it.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to