Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Paul,

Thanks for your assistance with this.   As you pointed out, it looks 
like Mike's suggestion was the answer, in the end.  But, I feel a lot 
better about it than when he suggested it, because at least now I know 
exactly what the cause of the problem is, I understand why it's 
necessary (needing to deal with blocking issues on something that's 
declared non-blocking is not very intuitive, but I understand why it's 
needed now) and you've tested it, so we know that it's the correct thing 
to do.

FWIW:  I looked into the internals of the OpenSSL code (since IBM 
doesn't share the internals of GSKit) and in OpenSSL they observe 
non-blocking correctly, but in order to do so, they return whether they 
need you to wait for input _or_ output data on a read call. In normal 
TCP, you'd never need anything besides input if you're reading the 
socket, or output if you're writing it.  So it's very weird that they 
can indicate either/or on an SSL Read.  It turns out that sometimes both 
sending/receiving are needed for the SSL code that happens behind the 
scenes.  I suspect that IBM did things a little differently, instead of 
signalling that they might need read or write whenn in non-blocking 
mode, they just decided to block during certain parts of the SSL 
exchange.  This way, they can hide those weird details from the caller, 
but at the same time, they can no longer do true non-blocking...   and 
that's the problem we ran into.  Not intuitive, and not documented 
anywhere that I can find.  But, since IBM has explained to us, we know 
what to do.

I've updated HTTPAPI to set the read timeout automatically (and to set 
it to the value you specify on the HTTP call rather than hard coding it 
to 5 minutes like you did).  This is now available in HTTPAPI 1.31.

-SK


On 2/2/2016 6:53 AM, Paul Kenosky wrote:
> Hello,
>
> Want to get back to everyone believe this problem is now solved on my end...
>
> How did I fix it? By doing what Mike suggested earlier...
>
>
> D readTimeOut     s             10I 0 inz(300000)
> ...
> ...
> ...
>
> rc = gsk_attribute_set_numeric_value(
>      wwSSLh: GSK_OS400_READ_TIMEOUT : readTimeOut);
> if rc <> GSK_OK;
>    SetError(HTTP_SSSNTO: 'Setting Read timeout: ' +
>        ssl_error(rc));
>    callp close(s);
>    gsk_secure_soc_close(wwsslh);
>    return *OFF;
> endif;
>
>
> .......
>
> When it locks up it appears to only lock up for 5mins now.... will prob change this to 1min at a later date...
>
> After troubleshooting with Scott and he saw from the log that it had been hanging on the gsk_read_secure_socket() he pointed me back to IBM
>
> Talking with IBM they suggested Setting Read Timeout because there are certain conditions that can cause a non-blocking socket to block
>
>
> Thanks for Helping,
> Paul John Kenosky

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------