Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

[Enrique de Montmollin <edm@xxxxxxxxxxxxxxxxxx>]

   Hi Scott,
   I have just dowloaded 1.31 and the installation fails while compiling
   Compatr4.
   RNF1503 Prototype not defined
   -----------------------------------------------------------------------
   -----------------------------------------------------------
   �P http_ParseURL � B � � � � � � � � � export � � � � �   � � � � � � � ��   �aaaaaaaaaaaaaaa � � � � � � � � � � � � � � � � � �   � � � � � � � � ��   3 30 a � � �042600 �No se ha definido anteriormente el prototipo
   para el
   � � � � � � � � � � procedimiento. � � � � � � � � �   � � � � � � � � ��   D http_ParseURL � PI � � � � � �10I 0 � � � � � � � � �   � � � � � � � �   -----------------------------------------------------------------------
   ----------------------------------------------------------
   P http_build_sockaddr... � � � � � � � � � � � � � � �   � � � � � � � ��   P � � � � � � � � B � � � � � � � � � export � � �   � � � � � � � � � ��   �aaaaaaaaaaaaaaa � � � � � � � � � � � � � � � � � �   � � � � � � � � ��   3 30 a � � �046500 �No se ha definido anteriormente el prototipo
   para el
   � � � � � � � � � � procedimiento. � � � � � � � � �   � � � � � � � � ��   D http_build_sockaddr... � � � � � � � � � � � � � � �   � � � � � � � ��   D � � � � � � � � PI � � � � � �10I 0 � � � � � �   � � � � � � � � � � �
   2016-02-03 5:29 GMT-03:00 Scott Klement <[1]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:
   [2]http://www.scottklement.com/mailman/listinfo/ftpapi
   -----------------------------------------------------------------------

References

   1. mailto:sk@xxxxxxxxxxxxxxxx
   2. http://www.scottklement.com/mailman/listinfo/ftpapi

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