[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging



Paul,

I'm trying to reproduce the problem you describe. I've created a web site that will simply sit and delay for 120 seconds, here:

https://www.profoundlogic.com:677/delay120

I am calling HTTPAPI with a shorter timeout than that to make sure it times out properly. I'll attach the code that I'm using. Unfortunately, this does not reproduce the problem, everything times out as expected.

Can you please take a look at the QRPGLESRC,CONFIG_H member in your HTTPAPI install library (LIBHTTP is the library name by default). and tell me what it says for HTTP_BLOCK_ON_CONNECT? This should have '/undefine' in front of it. If not, that's one possible problem.

Other than that, I don't know what else to do to help you here. I really need a way to reproduce this in order to help you.

-SK



On 1/15/2016 8:23 AM, Paul Kenosky wrote:
Is there an easy way of installing COMMSSLR4 without running the install pgm?

Thanks,
Paul John Kenosky



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Kenosky
Sent: Friday, January 15, 2016 9:12 AM
To: HTTPAPI and FTPAPI Projects
Subject: RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

Thanks Mike and Scott...

That made it a lot clearer... I made the required change for GSK_OS400_READ_TIMEOUT on the test box...
I'll get it over to production hopefully later today, and see if it gets an error over the weekend or sometime next week..



Paul John Kenosky



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Thursday, January 14, 2016 7:07 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

I have not made it that far into GSK understanding to know how it works the same or differently than using a select() timeout. But in the SSL communication mode, it appears that COMMSSL_READ is being used which uses gsk_secure_soc_read which does not include a timeout value.  So, it seems that the timeout value would be from someplace else.  Would that match your understanding?

When I was looking up this "new" value, I saw in the documentation page for the gsk_attribute_set_numeric_value that there is handshake timeout, a v2 session timeout, a v3 session timeout and a receive timeout. Since the OP seems to be having a timeout problem, maybe the GSKit uses its own timeout values unless you specify a different one? And both the 24 hours and wait forever seem to fit the scenario as posted by the OP. We know his timeout value is the default and yet the program appears to be waiting beyond 60 seconds. And since COMMSSLR4 already implements the handshake timeout, it seems like an easy thing to try for the OP.

The description of this operation
GSK_IBMI_READ_TIMEOUT (6993) - numValue is the receive time-out for the secure session or the SSL environment.
Also seems to fit. It doesn't preclude select() timeout from influencing it but it does seem to indicate the receive time-out for SSL should be set using this operation.

If that resolves the issue, then maybe the OP can lend some further evidence to whether the GSK_IBMI_READ_TIMEOUT matters or not.

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, January 14, 2016 4:26 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

Mike,

Timeouts in HTTPAPI are implemented with the select() API.  I am not using the GSK_OS400_READ_TIMEOUT (or GSK_IBMI_READ_TIMEOUT which is
exactly the same thing).   Are you saying that you can't have timeouts
in GSKit unless you set GSK_OS400_READ_TIMEOUT?

-SK


On 1/14/2016 3:41 PM, Mike Krebs wrote:
In HTTPAPI, this value is only defined as a constant and the value of the constant does not appear to have changed. I don't think that is the exact issue.

However, I don't see the read timeout being set the same way GSK_HANDSHAKE_TIMEOUT is being set. In COMMSSLR4 there is:

eval      rc = gsk_attribute_set_numeric_value(
            wwSSLh: GSK_HANDSHAKE_TIMEOUT: peTimeout)
if        rc <> GSK_OK
callp     SetError(HTTP_SSSNTO: 'Setting timeout: ' +
              ssl_error(rc))
callp     close(s)
callp     gsk_secure_soc_close(wwsslh)
return    *OFF
endif

The default timeout values are probably not what should be used. They are:

GSK_V2_SESSION_TIMEOUT set to 100 seconds.
GSK_V3_SESSION_TIMEOUT set to 86400 seconds (24 hours).
GSK_HANDSHAKE_TIMEOUT set to 0 (wait forever).
GSK_IBMI_RECEIVE_TIMEOUT set to 0 (wait forever).

Since the GSK_IBMI_RECEIVE_TIMEOUT is not set to peTimeout, is it waiting forever on a problem after the handshake or during the handshake when reading data from the server?

To test this since you are having the problem, change COMMSSLR4. Right after the section of code above do the same thing but substitute GSK_OS400_READ_TIMEOUT for the GSK_HANDSHAKE_TIMEOUT.  Change the error message slightly to indicate problem setting read timeout and recompile. The timeout value is supposed to be in milliseconds. You might want to hardcode a reasonable millisecond INT value. This part is little confusing to me as peTimeout is defined as packed(10:3) and it looks like it should be an INT. I also believe peTimeout is in seconds.

If this doesn't resolve maybe you have to set the GSK_V3_SESSION_TIMEOUT to a more reasonable number than 24 hours. That value is in seconds.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www-2D01.ibm.com_
support_knowledgecenter_ssw-5Fibm-5Fi-5F72_apis_gsk-5Fa&d=CwICAg&c=rxu
yg758I4Zd3CDHNny_Hw&r=JkfuZ4E665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=x9
7OiAiqpSs1bbrHPyYC1aPbGwoVFNZFwXUdGw7Qz04&s=uOat6-TdTfgPpv9AYY76zFfubv
nQFKsVzzpqud5lbR8&e=
ttribute_set_numeric_value.htm

Give it a whirl and see what happens.

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Paul
Kenosky
Sent: Thursday, January 14, 2016 1:31 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

Hey Scott,

Still trying to figure out why this is happening to the pgm...
I just got a response from IBM about this issue which I attached below..
Any idea?

//** email snip-it from IBM   **//
CUSTOMER REP: Paul
ACTION TAKEN: I sent him:
In the V7R2 documentation for GSK Toolkit the parameter name changed
from GSK_OS400_READ_TIMEOUT to GSK_IBMI_READ_TIMEOUT, but it was not
marked as "new" in the v7r2 documentation.  Check your code to see if
you are using the old parameter name.
Bob
//** END of email snip-it from IBM   **//



Thanks,
Paul John Kenosky


-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Klement
Sent: Monday, January 11, 2016 8:52 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging

Paul,

The web service provider shouldn't be able to prevent HTTPAPI from timing out.  Likewise, HTTPAPI should time out, no matter what your CHGTCPA network settings are.

Aside from a bug in HTTPAPI or the IBM i operating system, there shouldn't be anything that would prevent it from timing out.

Unfortunately, without being able to reproduce it on my own system, there's very little I can do.

-SK

On 1/11/2016 8:01 AM, Paul Kenosky wrote:
Hello Scott,

I am having trouble re-creating the problem myself now... It has not happened lately(about a week) since I been trying to catch it in debug... and hasn't happened on its nightly run... Unfortunately, I don't think I can share the code to the web service.

This is a new pgm connecting to a new web service, so I wonder if it could be something on their end that is not/was not setup correctly?

I am going to setup a loop on this pgm so it makes a call to the web service every 30mins, so hopefully I can catch it in debug.




-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Klement
Sent: Saturday, January 09, 2016 2:27 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FW: Help - HTTP_URL_POST_XML recvresp hanging

Paul Kenosky,

TCPKEEPALV is not a time-out value.  The default of two hours means that it'll send a packet every 2 hours to test the line and check if it's still active.  This shouldn't have any impact on HTTPAPI at all.

HTTPAPI should be doing it's own time out code.  And with all of the people using it (and there are a LOT) I've not run into this timeout code getting "stuck" not timing out.  Of course, that doesn't mean that you couldn't be unlucky and hit a bug that nobody else has, that's always possible...

In order to help further, I need to know how to reproduce the problem
you're seeing.  Basically, I need to be able to run your program on my own machine where I can debug/troubleshoot it.  Is that possible?
Unfortunately, a code snippet isn't good enough, I need something that I can actually run.

-SK


On 1/8/2016 12:50 PM, Paul Kenosky wrote:
Thanks for helping me through this...

I will look into CHGTCPA TCPKEEPALV(1) and see if that leads me anywhere... however you mention the default is 2 hours... I have left one of the hanging jobs run for about 6 hours before cancelling it....

As for the TimeOut value I am using default CONST which is I believe 60secs...

I am setting ccsids which im not really sure what it does or if I even need it...
(someone started the program and it was in there when I got it)

//** below is RPG code that is making the call **//
HTTP_SETCCSIDS ( 1208: 0);

           //'Call service to check address
           returnCode = HTTP_URL_POST_XML
              ( %trim(POSTLINK)
              : %addr(soapParms) + 2
              : %len(soapParms)
              : *null
              : %paddr(response)
              : %addr(returnUserData)
              : HTTP_TIMEOUT
              : HTTP_USERAGENT
              : 'text/xml; charset=utf-8'
              : %trim(ACTIONLINK)
              );

      if (returnCode <> 1);
        outError = 'Validation Call Failed';
      endif;
//** end RPG code that is making the call **//


---------------------------------------------------------------------
-
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.
c
om_mailman_listinfo_ftpapi&d=CwIF-g&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4
E
665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=JwWl0MErlXxRxXTt91ybq7HSdHmCQR
- KoiEe3mjB4gY&s=kqjXKsptSkcVv9bZp_7FwyWVrT6q9GeIl8YpGbDycVE&e=
---------------------------------------------------------------------
-
-
---------------------------------------------------------------------
-
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.
c
om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4
E
665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8GvW
W K0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
---------------------------------------------------------------------
-
-

----------------------------------------------------------------------
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.c
om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E
665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8GvWW
K0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
----------------------------------------------------------------------
-
----------------------------------------------------------------------
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.c
om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E
665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=x97OiAiqpSs1bbrHPyYC1aPbGwoVFNZ
FwXUdGw7Qz04&s=tcS16uOXWrFD-CGDdk2P3SG-xs8hAMCOVzkdN-RO4IQ&e=
----------------------------------------------------------------------
-
----------------------------------------------------------------------
- This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.c
om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E
665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=x97OiAiqpSs1bbrHPyYC1aPbGwoVFNZ
FwXUdGw7Qz04&s=tcS16uOXWrFD-CGDdk2P3SG-xs8hAMCOVzkdN-RO4IQ&e=
----------------------------------------------------------------------
-

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.com_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=x97OiAiqpSs1bbrHPyYC1aPbGwoVFNZFwXUdGw7Qz04&s=tcS16uOXWrFD-CGDdk2P3SG-xs8hAMCOVzkdN-RO4IQ&e=
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.com_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=x97OiAiqpSs1bbrHPyYC1aPbGwoVFNZFwXUdGw7Qz04&s=tcS16uOXWrFD-CGDdk2P3SG-xs8hAMCOVzkdN-RO4IQ&e=
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.com_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=6fI73r6NYcLQ5U79b_6EeJNtPIpHl2Fgy1tMWQ75dnA&s=jgrHEHv-SBUmri-5ZY8L9lupoyeT8g3MkYbgFQf980Y&e=
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------


     H DFTACTGRP(*NO) BNDDIR('HTTPAPI')

      /copy httpapi_h
      /copy ifsio_h

     D delay120        pr                  extpgm('DELAY120')
     D   peTimeout                   15p 5 const
     D delay120        pi
     D   peTimeout                   15p 5 const

     D QCMDEXC         PR                  ExtPgm('QCMDEXC')
     D   cmd                        200a   const
     D   len                         15p 5 const

     D RESULT          c                   '/tmp/timeouttest.html'
     D timeout         s             10i 0 inz(60)
     D rc              s             10i 0

      /free
        *inlr = *on;

        if %parms >= 1;
           timeout = peTimeout;
        endif;

        http_debug(*on);

        rc = http_get( 'https://www.profoundlogic.com:677/delay120'
                     : RESULT
                     : timeout
                     );
        if rc <> 1;
          http_crash();
        else;
          QCMDEXC('DSPF ''' + RESULT + '''': 200);
        endif;

        unlink(RESULT);
        return; 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------