hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HTTPCORE-236) Failed to receive last chunk of the large https response through httpcore-nio
Date Mon, 27 Sep 2010 12:57:34 GMT

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

Dmitry edited comment on HTTPCORE-236 at 9/27/10 8:56 AM:
----------------------------------------------------------

I was too fast to tell that this patch solves the problem.
I found another case when buffered input "eats" last chunk.

The method inputReady in the class SSLClientIOEventDispatch.java

This method calls conn.consumeInput() only when 
sslSession.isAppInputReady() returns true.

But actually conn (NHttpClientIOTarget) could be buffered. In my case it's a DefaultNHttpClientConnection.

So, I suggest additional change (probably it could be simplified):

public void inputReady(final IOSession session) {
    NHttpClientIOTarget conn =
        (NHttpClientIOTarget) session.getAttribute(ExecutionContext.HTTP_CONNECTION);
    SSLIOSession sslSession =
        (SSLIOSession) session.getAttribute(SSL_SESSION);

    try {
        if(conn instanceof SessionBufferStatus){
            //we have buffered NHttpClientIOTarget, let,s check buffer also...
            boolean hasBufferedInput = hasBufferedInput=((SessionBufferStatus)conn).hasBufferedInput();
            //DLukyanov: i'm not sure that the next "if" operator is necessary...
            //   better will be if NHttpClientIOTarget itself will decide if consume will
be effective or not.
            if (sslSession.isAppInputReady() || hasBufferedInput) {
                conn.consumeInput(this.handler);
            }
        }else{
            //just try to consume. we can't guess if it's buffered or not
            conn.consumeInput(this.handler);
        }
        //ORIGINAL CODE:
        //if (sslSession.isAppInputReady()) {
        //    conn.consumeInput(this.handler);
        //}
        
        sslSession.inboundTransport();
    } catch (IOException ex) {
        this.handler.exception(conn, ex);
        sslSession.shutdown();
    }
}


      was (Author: daggett):
    I was too fast to tell that this patch solves the problem.
I found another case when buffered input "eats" last chunk.

The method inputReady in the class SSLClientIOEventDispatch.java

This method calls conn.consumeInput() only when 
sslSession.isAppInputReady() returns true.

But actually conn (NHttpClientIOTarget) could be buffered. In my case it's a DefaultNHttpClientConnection.

So, I suggest additional change (probably it could be simplified):

public void inputReady(final IOSession session) {
	NHttpClientIOTarget conn =
		(NHttpClientIOTarget) session.getAttribute(ExecutionContext.HTTP_CONNECTION);
	SSLIOSession sslSession =
		(SSLIOSession) session.getAttribute(SSL_SESSION);

	try {
		if(conn instanceof SessionBufferStatus){
			//we have buffered NHttpClientIOTarget, let,s check buffer also...
			boolean hasBufferedInput = hasBufferedInput=((SessionBufferStatus)conn).hasBufferedInput();
			//DLukyanov: i'm not sure that the next "if" operator is necessary...
			//   better will be if NHttpClientIOTarget itself will decide if consume will be effective
or not.
			if (sslSession.isAppInputReady() || hasBufferedInput) {
				conn.consumeInput(this.handler);
			}
		}else{
			//just try to consume. we can't guess if it's buffered or not
			conn.consumeInput(this.handler);
		}
		//ORIGINAL CODE:
		//if (sslSession.isAppInputReady()) {
		//    conn.consumeInput(this.handler);
		//}
		
		sslSession.inboundTransport();
	} catch (IOException ex) {
		this.handler.exception(conn, ex);
		sslSession.shutdown();
	}
}


  
> Failed to receive last chunk of the large https response through httpcore-nio 
> ------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-236
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-236
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.1-beta2
>         Environment: java 1.6_06 windows xp, linux redhat.
>            Reporter: Dmitry
>            Priority: Critical
>             Fix For: 4.1
>
>         Attachments: SSLClientIOEventDispatch.diff, SSLIOSession.diff
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> I'm a wso2 esb (synapse) user/developer.
> I got a problem with https nio transport.
> I tried versions 4.1 alpha1 and 4.1 beta2.
>  
> The problem: 
> transport failed to receive large (50k) response through nio https.
> The connection is keep-alive and chunked. Every time I received only response divisible

> by 8192 and last chunk is never returned.
>  
> After digging the logs and code I found that last chunk not returned because 
> of the code in this class org.apache.http.impl.nio.reactor.SSLIOSession.java
>  
> I changed one line in the code and now it's working.
> Now I want to ask somebody who knows the code if this change is ok,
> and maybe it should be applied to httpcore (see attached file)

-- 
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message